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This  report  presents  a  dynamic  mesh  representation  that  is  designed  to  display 
the  results  of  interactively  sampling  a  3D  environment.  The  mesh  generator  takes 
samples  comprising  a  world  space  location,  RGB  color  value,  and  sampled  ray 
direction,  and  assembles  them  into  a  3D  triangle  mesh.  From  this  representation 
a  complete  image  can  be  constructed  and  displayed,  both  from  the  initial  view, 
and  from  subsequent  views  as  the  user  moves  through  the  environment.  The 
representation  exploits  the  fact  that  from  a  hxed  vantage  point  there  is  a  one-to- 
one  mapping  between  visible  world  space  points  and  their  projection  onto  a  sphere 
centered  at  that  viewpoint.  A  Delaunay  triangulation  constructed  on  the  sphere 
provides  the  mesh  topology  and  the  the  vertex  coordinates  are  derived  from  the 
input  samples.  The  resulting  mesh  is  used  as  the  2.5D  display  representation. 
The  mesh  is  dynamic  and  ephemeral:  it  is  updated  as  samples  are  added  and 
deleted,  and  reconstructed  after  signihcant  viewpoint  changes. 

The  dynamic  mesh  representation  is  described  in  the  context  of  an  interactive 
rendering  system  based  on  the  holodeck,  a  4-dimensional  ray-caching  data  struc¬ 
ture.  In  the  holodeck  system,  a  display  driver  makes  requests  for  ray  samples 
based  on  the  user’s  current  view.  The  display  driver  must  then  quickly  construct 
a  coherent  image  based  on  these  samples.  This  report  introduces  the  dynamic 
mesh  representation  as  a  solution  to  the  reconstruction  problem,  describes  its 
implementation,  and  presents  the  results  of  utilizing  this  representation  in  the 
holodeck  environment. 
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1  Introduction 


The  interactive,  realistic  rendering  of  complex  environments,  real  and  virtual,  is  a  longstanding  goal  in  the 
held  of  computer  graphics.  We  have  the  ability  to  calculate  full  global  illumination  solutions,  producing 
the  diffuse  and  view-dependent  effects  necessary  to  impart  a  realistic  percept  of  an  environment.  Real- 
world  environments  can  be  captured  via  scanners  and  photographs  utilizing  computer  vision  techniques. 
Visibility  algorithms  and  graphics  hardware  advances  allow  the  interactive  exploration  of  complex  virtual 
environments.  Incorporating  all  of  these  capabilities  into  a  single  system,  however,  continues  to  pose  a 
challenge. 

Interactive  ray-tracers  offer  one  class  of  solutions  to  this  problem.  One  such  method  is  based  on  the 
holodeck  [6,  17],  a  four-dimensional  ray-caching  data  structure  which  serves  as  a  rendering  target  and 
caching  mechanism  for  interactive  walk-throughs  of  non-diffuse  environments  with  full  global  illumina¬ 
tion.  In  the  holodeck  system,  a  display  driver  makes  requests  for  ray  samples  based  on  the  user’s  current 
view.  A  server  gathers  the  relevant  samples,  hrst  sending  those  that  are  cached  in  the  holodeck  from 
previous  views,  and  then  requesting  additional  rays  to  be  traced  for  the  current  view.  Ray  samples  are 
generated  by  the  Radiance  lighting  simulation  system  [8,  16].  The  display  driver  takes  the  requested 
samples  from  the  server  and  converts  them  into  a  suitable  display  representation.  This  requires  mapping 
world  floating-point  colors  to  displayable  RGBs  and  constructing  a  coherent  image.  The  driver  must 
continue  to  update  this  image  during  progressive  rehnement  as  new  values  are  computed  by  the  sample 
generator  and  passed  on  by  the  server.  The  system  expects  a  certain  interactive  rhythm  from  the  user, 
in  the  form  of  slow,  inertial  view  changes,  with  stationary  observation  phases  in  between.  During  view 
motion,  no  new  samples  are  provided  by  the  server  and  the  display  driver  must  make  do  with  the  existing 
representation  to  provide  sufhcient  visual  feedback. 

This  report  presents  a  dynamic  mesh  representation  as  a  solution  to  the  reconstruction  problem, 
describes  its  implementation,  and  presents  the  results  of  utilizing  this  representation  in  an  interactive 
rendering  system  based  on  the  holodeck  ray-cache.  The  mesh  generator  takes  samples  comprising  a  world 
space  location,  RGB  color  value,  and  sampled  ray  direction,  and  assembles  them  into  a  3D  triangle  mesh. 
From  this  representation  a  complete  image  can  be  constructed  and  displayed,  both  from  the  initial  view, 
and  from  subsequent  views  as  the  user  moves  through  the  environment.  Gouraud-shaded  triangles  are 
displayed  both  during  motion  and  afterwards  during  progressive  rehnement.  The  advantage  of  such  a 
representation  is  threefold.  Firstly,  triangles  are  rendered  and  Gouraud-shaded  by  the  graphics  hardware, 
providing  barycentric  interpolation  of  radiance  between  spatially  adjacent  samples.  Secondly,  since  the 
representation  explicitly  contains  the  3D  information  for  each  sample,  and  not  just  a  representation 
of  the  projections  for  a  particular  view,  the  rendering  representation  can  be  re-used  between  frames 
for  small  view  motions.  Finally,  since  the  generator  utilizes  the  sample  data  exclusively  to  build  the 
representation,  it  can  be  used  without  additional  or  a  priori  knowledge  of  the  scene  geometry. 

The  representation  exploits  the  fact  that  from  a  hxed  vantage  point  there  is  a  one-to-one  mapping 
between  visible  world  space  points  and  their  projection  onto  a  sphere  centered  at  that  viewpoint.  In 
this  sense  the  samples  form  a  height  held,  and  we  can  reduce  the  3D  meshing  problem  to  a  2D  triangu¬ 
lation  on  the  sphere.  A  Delaunay  mesh  constructed  on  the  sphere  provides  the  mesh  topology  and  the 
vertex  coordinates  are  derived  from  the  input  samples.  The  resulting  mesh  is  used  as  the  2.5D  display 
representation.  We  maintain  the  Delaunay  condition  on  the  mesh  to  improve  both  image  quality  and 
robustness  of  the  meshing  code.  Such  a  triangulation  provides  a  reasonable  interpolation  and  maximizes 
the  minimum  angle  and  therefore  minimizes  rendering  artifacts  caused  by  long  thin  triangles.  Such 
triangles  could  also  prove  problematic  during  the  computation  and  manipulation  of  the  mesh  as  they 
are  prone  to  producing  topological  inconsistencies  due  to  round-off  errors  in  the  calculations. 

The  mesh  contains  sufficient  information  to  render  the  scene  from  any  viewing  conhguration  based  at 
the  initial  or  “canonical”  viewpoint  from  which  the  mesh  is  constructed.  If  the  observer  moves  slightly 
off  the  viewpoint,  the  same  mesh  is  maintained  and  used  as  the  rendering  representation.  The  sample 
points  are  re-projected  as  the  mesh  is  transformed  and  rendered  by  the  graphics  hardware.  In  the  case 
of  small  view  motions  without  signfficant  visibility  changes,  the  resulting  image  will  not  suffer  noticeable 


2 


artifacts.  Once  the  observer  moves  a  significant  distance  from  the  canonical  viewpoint,  the  current  mesh 
is  discarded  and  a  new  mesh  is  constructed  with  the  current  sample  set  projected  relative  to  the  new 
canonical  viewpoint.  To  make  this  reconstruction  faster,  only  those  samples  that  fall  into  the  current 
view  frustum  are  added  to  the  new  mesh.  The  mesh  is  therefore  dynamic  and  ephemeral:  it  is  updated 
as  samples  are  added  and  deleted,  and  reconstructed  after  signihcant  viewpoint  changes. 

The  remainder  of  this  section  describes  the  format  of  the  input  samples  that  are  received  from 
the  driver  and  from  which  the  display  representation  must  be  progressively  constructed.  The  rest  of 
the  paper  describes  the  dynamic  mesh  representation,  and  algorithms  for  its  construction  and  display. 
Results  of  utilizing  the  dynamic  mesh  representation  in  the  holodeck  environment  are  presented,  and 
the  representation  is  evaluated  in  this  context.  The  report  concludes  with  ideas  for  improvements  and 
future  work.  Appendix  A  includes  a  specihcation  of  the  display  driver  interface  for  the  holodeck  system. 

1.1  Input 

As  the  user  moves  about  in  an  environment  visualized  using  the  holodeck  system,  samples  are  fetched 
from  cache  for  each  new  view  and  sent  to  the  display  driver.  New  rays  are  then  generated  by  any  number 
of  ray  tracing  processes  and  also  passed  on  to  the  display  driver.  In  this  system,  the  display  driver  has 
no  control  over  how  many,  or  what  samples  it  receives  at  any  given  time.  The  display  generation  process 
must  be  able  to  assimilate  whatever  samples  it  is  given  as  quickly  as  possible  into  a  coherent  image  for 
display,  which  should  progressively  rehne  as  more  samples  arrive. 

For  each  sample  in  a  given  view,  the  driver  provides  the  3D  coordinates,  a  4  component  (RGBE 
[15])  color  value,  and  a  ray  direction.  The  coordinate  value  is  the  intersection  point  of  the  ray  with 
the  environment,  and  can  represent  a  world  space  point  or  a  direction,  in  the  case  that  the  intersection 
occurs  at  inhnity  (or  effectively  so).  A  tone-mapping  operation  [7]  is  periodically  applied  to  the  color 
value  to  generate  a  renderable  RGB  value  based  on  the  current  set  of  samples,  allowing  input  samples 
with  high  dynamic  range  to  be  displayed  without  perceived  loss  of  visual  information.  The  ray  direction 
is  the  direction  from  which  the  intersection  point  was  calculated.  Because  the  holodeck  server  utilizes  a 
cache  and  re-uses  rays  for  alternate  views,  this  information  is  not  redundant.  Samples  returned  by  the 
server  may  not  pass  exactly  through  the  current  eye  point.  The  ray  direction  can  be  used  to  determine 
how  close  the  sample  ray  passed  to  the  actual  ray  from  the  current  viewpoint  as  a  measure  of  relative 
sample  quality. 


Figure  1:  Multi-depth  values:  a)  A  viewing  situation  in  plan  view.  The  solid  ray  returns  the  correct  visible  sample  for 
view  A.  If  the  same  ray  is  re-used  for  view  B,  it  can  return  a  point  that  should  be  occluded,  b)  An  example  reconstruction 
using  only  rays  from  the  current  view,  c)  The  view  is  pivoted  about  the  chair,  and  rays  are  re-used.  Multi-depth  artifacts 
can  be  seen  along  the  chair’s  silhouette. 


In  the  case  of  a  sample  with  an  intersection  point  at  inhnity,  the  direction  value  passed  is  set 
to  invalid,  and  the  coordinate  value  contains  the  ray  direction.  These  directional  samples  represent 
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background  scenery.  In  the  rest  of  this  report  such  samples  are  referred  to  as  background  points  to 
differentiate  them  from  the  world  space,  or  foreground  points.  Background  samples  are  incorporated 
directly  into  the  mesh  with  the  world  space  points,  but  require  special  processing  during  re-projection 
and  rendering. 

When  the  ray  sample  is  re-projected  to  the  expected  position  in  a  new  view,  we  may  get  a  sample  that 
is  actually  behind  a  foreground  object  when  we  re-project  its  location  (see  Figure  la).  Such  multi-depth 
samples  occur  near  object  silhouettes  and  can  produce  visible  artifacts  in  the  rendering,  appearing  as 
small  holes  piercing  through  the  object’s  visible  boundary  (see  Figure  Ic).  Even  when  the  multi-depth 
sampling  is  minimal,  the  artifact  can  still  be  marked,  given  the  human  visual  system’s  sensitivity  to 
silhouette  boundaries.  As  more  rays  are  traced  during  progressive  rehnement,  sufhciently  many  correct 
samples  will  eventually  be  generated  and  will  replace  the  incorrect  ones  in  the  representation. 

The  following  sections  discuss  techniques  for  generating  and  rendering  meshes  for  display  based  upon 
the  type  of  input  described  above. 

2  Mesh  Construction 

Given  the  holodeck  environment,  we  need  a  mesh  data  structure  that  supports  the  following  operations: 

•  Fast  insertion  of  a  new  sample  into  the  mesh:  requires  point  location. 

•  Deletion  of  samples:  not  as  common  -  but  also  must  be  fast 

•  View  frustum  culling 

Given  a  specihed  view  and  a  set  of  samples,  the  goal  of  representation  generation  is  to  quickly 
display  a  coherent  image  that  is  a  viable  representation  of  the  potentially  sparse  set  of  sample  points.  The 
representation  should  support  progressive  rehnement  while  the  view  is  stationary  and  provide  reasonable 
interactivity  during  motion.  There  is  clearly  a  tradeoff  between  the  quality  of  the  resulting  image  and 
the  time  spent  during  reconstruction.  We  have  chosen  a  3D  Gouraud-shaded  mesh  as  the  base  display 
representation.  With  such  a  primitive  we  can  exploit  existing  graphics  hardware  to  do  simple  and  fast 
interpolation  of  sample  values,  rendering  of  the  mesh,  and  view  transformations  during  motion,  re-using 
the  same  representation  between  adjacent  views. 

Given  a  single  view,  other  researchers  have  chosen  to  build  a  two-dimensional  Delaunay  triangulation 
of  the  projected  samples  on  the  image  plane  as  a  solution  to  the  reconstruction  problem  [2,  10,  13]. 
While  this  basic  approach  provides  a  reasonable  barycentric  interpolation  of  the  radiance  values,  the 
samples  must  be  re-projected  and  the  mesh  reconstructed  each  frame  to  provide  a  coherent  image  during 
viewer  motion.  Alternate  approaches  utilize  the  projected  points  to  determine  the  mesh  topology  in  two 
dimensions,  but  retain  the  original  3D  information  in  the  resulting  vertices,  resulting  in  a  2.5D  mesh 
representation,  which  can  be  rendered  from  alternate  viewpoints  [14,  3].  This  allows  only  limited  view 
motion;  artifacts  will  appear  as  soon  as  the  viewer  moves  enough  to  reveal  new  areas  in  the  scene. 

In  the  dynamic  mesh  representation,  we  also  exploit  the  2.5D  nature  of  the  data  in  the  construction 
of  the  mesh.  In  the  holodeck  environment,  the  sample  data  (excluding  multi-depth  samples)  is  a  height 
held  relative  to  a  given  view  location.  We  dehne  a  unit  sphere  centered  at  the  eye  point  and  project  the 
samples  onto  the  spherical  surface  -  reducing  the  problem  to  triangulation  on  the  sphere.  A  Delaunay 
mesh  constructed  on  the  sphere  provides  the  mesh  topology,  and  the  vertices  are  derived  from  the  input 
samples.  Given  the  initial  view,  the  view  sphere  is  centered  at  the  eye  point.  This  initial  point  is  called 
the  “canonical”  viewpoint  and  may  or  may  not  coincide  with  the  current  eye  location  as  the  simulation 
progresses.  A  base  mesh  is  created  that  covers  the  surface  of  the  sphere.  The  base  mesh  is  represented  in 
Figure  2a.  In  Figure  2b,  an  example  sample  set  is  projected  onto  the  view  sphere,  and  the  corresponding 
spherical  mesh  is  shown  in  2c. 

Given  a  new  sample,  we  perform  point  location  to  hnd  the  existing  spherical  mesh  triangle  that 
encloses  its  projection.  If  the  projection  of  the  new  sample  coincides  with  that  of  an  existing  sample,  the 
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Figure  2:  Spherical  mesh  a)  Base  icosahedral  mesh  b)  Projected  set  of  samples  c)  Resulting  spherical  mesh 


sample  whose  direction  passes  closest  to  the  current  view  direction  is  retained.  Otherwise,  the  sample 
point  is  inserted  into  the  triangle,  creating  three  new  triangles  if  the  new  sample  falls  interior  to  an 
existing  triangle,  or  four  if  it  falls  on  an  edge  (see  Figure  3).  The  Delaunay  condition  is  tested  for  each 
new  triangle,  and  reasserted  if  necessary.  We  have  adapted  a  planar  Delaunay  triangulation  algorithm 
[5,  9]  to  work  on  the  sphere.  Sample  points  may  also  be  deleted  from  the  mesh.  In  this  case,  the  sample 
is  removed,  as  well  as  all  of  its  adjacent  triangles.  The  resulting  hole  is  re-triangulated,  and  the  Delaunay 
condition  is  reasserted  for  all  new  triangles. 


Figure  3:  Point  Insertion:  a)  Sample  p  falls  inside  existing  triangle:  3  new  triangles  are  created,  b)  Sample  p  falls  on 
edge  :  4  new  triangles  are  created. 


In  the  following  sections  we  discuss  the  basic  mesh  structure,  the  implementation  of  the  tasks  of 
sample  insertion  and  sample  deletion,  and  the  use  of  a  point  location  data  structure  to  make  these  tasks 
more  efficient.  We  conclude  the  section  with  a  discussion  of  robustness  issues. 

2.1  Mesh  structure 

Our  implementation  maintains  the  mesh  as  a  list  of  triangles  with  vertex  and  neighbor  pointers.  This 
is  the  rendering  representation.  A  second,  spatial  data  structure  is  maintained  to  support  the  efficient 
execution  of  operations  on  the  mesh.  Samples  are  stored  in  a  hxed  size  ID  array  whose  maximum  size 
is  specffied  at  startup.  The  mesh  vertices  are  derived  from  these  samples.  A  hxed  size  triangle  list  is 
also  created  at  initialization.  The  maximum  number  of  triangles  in  the  spherical  mesh  is  bounded  by 
the  number  of  samples  and  number  of  triangles  in  the  base  mesh.  If  h  is  the  number  of  triangles  in  the 
base  mesh  and  s  is  the  maximum  sample  count,  then  the  maximum  number  of  triangles  is  (&-l-2s)  .  The 
insertion  of  each  sample  deletes  an  existing  triangle  and  creates  3  new  triangles,  or  deletes  2  existing 
triangles  and  creates  4  new  ones.  The  triangles  store  pointers  to  their  vertices,  and  to  the  3  neighboring 
triangles.  Samples  contain  a  pointer  to  one  of  their  adjacent  triangles;  the  rest  can  be  found  by  triangle 
neighbor  traversal. 

Existing  in  parallel  with  the  3D  mesh  is  the  notion  of  a  spherical  mesh.  This  mesh  is  the  projection 
of  the  3D  mesh  onto  a  unit  sphere  centered  at  a  particular  viewpoint,  the  canonical  viewpoint,  from 
which  the  mesh  is  constructed.  This  exists  more  as  a  concept  then  a  data  structure  in  its  own  right,  as 
the  only  stored  information  for  this  mesh  is  the  canonical  viewpoint.  The  rest  of  the  data  is  shared  with 
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or  derived  from  the  3D  mesh. 

At  initialization  time  a  base  spherical  mesh  is  created  that  tiles  the  view  sphere.  The  base  mesh  is 
an  icosahedral  subdivision  of  the  sphere.  Figure  2a  shows  the  base  mesh  and  Section  2.4  discusses  the 
motivation  for  such  a  choice  in  detail.  This  mesh  is  created  as  a  starting  point,  so  sample  insertion  will 
have  something  to  insert  into.  The  vertices  and  triangles  comprising  the  base  mesh  are  referred  to  as  base 
vertices  and  base  triangles.  These  are  really  just  place-holders  that  are  necessary  to  maintain  consistent 
mesh  topology.  These  vertices  and  triangles  are  stored  separately  at  the  end  of  the  mesh  sample  and 
triangle  array  to  identify  them  as  being  extraordinary  entities.  The  base  points  are  calculated  to  lie  on 
the  sphere  centered  at  the  canonical  viewpoint  specihed  at  initialization  time. 


2.2  Sample  insertion 

Once  the  base  mesh  has  been  initialized,  samples  can  be  incrementally  inserted  into  the  mesh.  There 
is  a  one-to-one  mapping  of  visible  world  space  samples  and  their  projection  on  the  view  sphere.  The 
possibility  of  multi-depth  values  requires  special  checking  at  insertion  time,  but  it  is  possible  to  choose 
one  of  the  samples  as  being  preferable  if  two  projections  coincide  (this  test  is  covered  in  Section  2.2.2). 
All  mesh  insertion  and  deletion  operations  are  applied  at  the  conceptual  level  to  the  spherical  mesh. 
In  this  way,  we  can  simplify  the  problem  of  3D  mesh  construction  by  reducing  the  dimensionality  to 
a  spherical  surface.  Because  of  the  height-held  characteristic  of  the  data,  the  mesh  topology  can  be 
calculated  on  the  sphere  and  then  utilized  for  the  3D  mesh  merely  by  replacing  the  projected  vertex 
coordinates  with  their  original  world  space  coordinates. 

Given  a  new  sample  point,  we  hrst  must  determine  which  spherical  mesh  triangle  encloses  the  sample’s 
spherical  projection  relative  to  the  canonical  view.  All  points  inside  the  space  enclosed  by  the  pyramid 
with  apex  at  the  canonical  viewpoint  and  dehned  by  the  world  space  coordinates  of  a  triangle  will  project 
to  that  spherical  triangle.  The  process  of  point  location  is  discussed  in  detail  in  Section  2.2.1.  Once  we 
hnd  the  appropriate  triangle,  we  hrst  test  if  the  sample  should  be  added  to  the  mesh.  This  test  is  based 
on  the  density  and  quality  of  samples  in  the  nearby  area  and  is  discussed  in  Section  2.2.2. 


2.2.1  Point  Location 

We  maintain  a  separate  triangle-based  quadtree  data  structure  to  accelerate  point  location.  Associated 
with  the  view  sphere  is  an  octahedron  in  canonical  form  (origin  at  the  canonical  viewpoint,  aligned  with 
coordinate  axes)  that  subdivides  the  sphere  surface  into  eight  uniform  spherical  triangles.  A  triangular 
quadtree  is  created  on  each  octahedral  face  (see  Figure  4a, b).  Each  quadtree  cell  contains  a  list  of  the 
samples  that  fall  in  that  cell.  The  task  of  point  location  is  to  locate  the  mesh  triangle  that  a  new  sample 


Figure  4:  Point  location  structure  a)  Quadtree  roots  on  the  octahedron  b)  Corresponding  spherical  representation  c) 
Octant  labeling. 


falls  in.  To  perform  point  location,  we  hrst  hnd  which  octant  the  point  falls  in,  thereby  identifying  the 
appropriate  quadtree  root  node.  The  quadtree  is  then  traversed  until  the  appropriate  leaf  is  located. 
Once  the  leaf  is  located,  a  sample  is  extracted  from  the  set  and  the  new  sample  is  tested  for  inclusion 
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with  the  adjacent  triangle.  If  the  new  sample  does  not  fall  in  the  triangle,  a  walk  is  performed  along  the 
mesh  surface  until  the  desired  triangle  is  located.  We  describe  these  steps  in  more  detail  below. 

Given  a  new  sample,  we  hrst  subtract  off  the  canonical  viewpoint  such  that  the  coordinate  point  is 
dehned  relative  to  the  view  sphere.  This  operation  is  unnecessary  in  the  case  of  a  directional  point.  Next 
the  spherical  octant  containing  the  point  is  identihed.  Due  to  the  alignment  of  the  octree,  this  operation 
is  trivial.  The  octants  are  numbered  from  0-7  as  indicated  in  Figure  4c.  The  octants  are  labeled  with  a 
3  bit  identiher,  where  the  high  order  bit  is  set  if  the  octant  is  in  the  negative  side  of  the  z=0  plane,  the 
second  order  bit  is  set  if  the  octant  is  on  the  negative  side  of  the  y=0  plane,  and  the  lowest  order  bit  set 
similarly  for  x.  Given  a  3D  point  p,  the  octant  identiher  I  is  calculated  as  in  the  following  pseudo-code: 

I  =(p[2]  >  0.0?0:4)  I  (p[l]  >  0.0?0:2)  I  (p[0]  >  0.0?0:1) 

Once  the  octant  is  located,  the  point  is  converted  into  integer  barycentric  coordinates  (a,  h,  c)  relative 
to  the  triangle  go9i92  forming  the  quadtree  root  for  that  octant.  The  point  v  is  projected  into  the  plane  of 
the  quadtree  root  triangle.  Since  the  octant  plane  equations  are  all  of  the  form  Ax  +  By  +  Cz  =  D,  where 
A,  B,C,  D  =  ±1,  we  can  hrst  normalize  the  point  to  the  x  +  y  +  z  =  1  frame  by  scaling  its  coordinates 
by  A,  B,  C  of  the  plane  equation,  resulting  in  v' .  The  barycentric  coordinates  relative  to  this  frame  are 
calculated  by  taking  the  intersection  of  the  ray  v'  with  x  +  y  +  z  =  1  or  p  =  +  ^'^[2]- 

The  values  of  the  coordinates  will  be  in  [0.0,  1.0].  In  Figure  5a,  the  point  v  projects  to  point  p  in  the 
quadtree  plane.  Figure  5b  shows  the  local  barycentric  coordinate  system  for  the  quadtree  root  with 
vertices  go,9i,92-  In  Figure  5c,  the  barycentric  coordinate  pb,  has  been  calculated  at  level  0  in  the 
quadtree. 


Figure  5:  Quadtree  traversal  a)  Identifying  sample  projection  on  quadtree  b)  Barycentric  coordinate  system  of  quadtree 
root  c,d,e)  Barycentric  coordinates  for  point  p  at  level  0,1,2,  respectively 

The  barycentric  coordinates  are  then  converted  into  integer  values  for  calculation  efficiency.  The 
range  [0.0,  1.0]  is  mapped  to  [0,  5],  where  B  is  set  such  that  the  range  fits  into  an  unsigned  long  on  the 
target  architecture  with  one  bit  to  spare  to  prevent  overflow  during  addition  of  two  valid  numbers  in  the 
range. 

The  quadtree  is  then  traversed  until  the  appropriate  leaf  is  located.  This  operation  is  efficient, 
requiring  only  integer  shifts  and  adds.  Given  the  barycentric  coordinate  of  the  point  at  level  i,  Pb(i), 
and  a  quadtree  node,  we  can  calculate  which  child  Pb(i)  falls  in  at  the  next  level  in  the  quadtree.  At  the 
same  time  we  adjust  the  coordinates  of  Pb(i)  relative  to  the  new  coordinate  frame  of  the  child,  producing 
Pb(i+i)-  Figure  5d  shows  the  numbering  of  the  children  and  the  defining  half-spaces.  For  expository 
purposes,  the  examples  use  the  floating  point  values  of  the  coordinates;  in  practice  the  integer  values 
are  used. 
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The  following  pseudo-code  implements  the  child  identihcation  and  coordinate  adjustment. 


int  bary_child(b) 

if(b[0]  >  B/2)  /  +  IN  child  0  +/ 

b[0]  =  (b[0]  «  1)  -  B;  b[l]  «=  1;  b[2]  «=1;  return(O) 
if(b[l]  >  B/2)  /+  IN  child  1  +/ 

b[0]  «=  1;  b[l]  =  (b[l]  «  1)  -  B;  b[2]  «=  1;  return(l) 
if(b[2]  >  B/2)  /+  IN  child  2  +/ 

b[0]  «=  1;  b[l]  «=  1;  b[2]  =  (b[2]  «  1)  -  B;  return(2) 

/+  IN  child  3  +/ 

b[0]  =  B  -  (b[0]  «  l);b[l]  =  B  -  (b[l]  «  1);  b[2]=  B  -  (b[2]  «  1);  return(3) 


In  Figure  5e,  the  coordinates  relative  to  child  1  have  been  calculated.  Figure  5f  shows  the  results  at  level 
2.  Note  that  when  the  center,  or  number  3  child  is  traversed,  the  orientation  of  the  triangle  is  flipped  so 
that  the  coordinates  correspond  to  the  same  dehning  half-spaces. 

This  traversal  continues  until  the  leaf  level  is  reached.  Once  the  leaf  is  located,  we  select  the  hrst 
sample  in  the  set.  We  could  alternatively  choose  the  sample  that  is  closest  to  the  new  point,  but  in 
practice  we  hud  that  we  get  good  performance  with  choosing  the  hrst  sample  (average  of  8  triangles 
visited  on  the  walk),  and  it  is  therefore  not  necessary  to  perform  the  expensive  test  of  comparing  the 
new  sample  to  each  one  in  the  set  to  hnd  the  closest.  It  may  be  possible  that  the  leaf  cell  contains  no 
samples.  In  this  case  we  recursively  pop  back  up  in  the  quadtree  traversal  until  a  leaf  is  found  that  does 
contain  some  samples. 

Each  sample  stores  a  pointer  to  one  of  its  adjacent  triangles.  This  triangle  is  retrieved  and  tested 
to  see  if  it  contains  the  new  point.  To  test  if  the  projection  of  the  point  onto  the  sphere  lies  within  a 
particular  spherical  triangle,  we  can  test  the  position  of  the  point  relative  to  each  of  the  planes  forming 
the  pyramid  with  apex  at  the  canonical  viewpoint,  and  passing  through  the  world  space  triangle,  or 
equivalently  against  the  great  circles  forming  the  spherical  triangle.  If  the  point  lies  inside  of  all  three 
planes,  it  is  accepted  as  being  inside  the  triangle.  If  any  one  of  the  tests  fail,  the  test  traverses  to  the 
triangle  adjacent  to  the  current  one  across  the  plane  (edge)  for  which  the  test  failed. 


Figure  6:  Orientation  test:  if  (p  •  n)  >  0  (as  with  pi),  the  point  is  inside  edge  ah.  The  angle  distance  between  the  point 
p  and  edge  ah  is  (-j  —  cos“^  O') 

We  also  want  to  know  how  close  the  input  point  lies  to  the  spherical  edge,  to  ensure  robustness  in 
the  test  (see  Section  2.4).  Given  a  new  sample,  we  calculate  the  angle  separation  between  the  spherical 
point  p  and  the  spherical  edge  ah  (see  Figure  6).  If  n  is  the  normal  to  the  great  circle  dehned  by  the 
edge  ah,  the  dot  product  {p  ■  n)  gives  the  cosine  of  the  angle  between  the  normal  n  and  the  point  p.  If  the 
point  lies  within  [0,  j]  above  the  edge,  0  <  (p  •  n)  <  1.  If  the  point  p  lies  within  (0,  j]  below  the  edge, 
—  1  <  (p  •  n)  <  0.  The  angle  distance  a  between  the  point  p  and  the  edge  ah  is  a  =  ^  —  cos“^(p  •  n).  The 
derivative  of  j/  =  cos6,  ^  =  sinO,  has  an  absolute  minimum  at  6*  =  0  and  maximum  at  6*  =  -1.  Our  angle 
test  is  therefore  less  sensitive  to  small  changes  in  (p  •  n)  when  p  is  very  close  to  ah,  i.e.  cos~^  (p  ■  n)  « 
This  makes  the  test  less  susceptible  to  errors  caused  by  round-off  error  in  the  calculation  of  cos  9. 

We  are  guaranteed  to  hnd  the  appropriate  triangle.  Firstly,  there  will  be  a  triangle,  since  the  surface  of 
the  view  sphere  is  completely  tiled  with  spherical  triangles.  Secondly,  because  of  the  spherical  Delaunay 
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topology,  we  are  guaranteed  to  converge  upon  the  correct  triangle,  without  re-visiting  any  mesh  triangles 
along  the  way.  Section  2.4  discusses  how  the  geometric  predicates  are  implemented  in  this  algorithm  to 
ensure  robustness. 

Initially,  we  had  implemented  the  point  location  based  on  storing  triangles  in  the  quadtree  structure. 
With  this  implementation,  the  mesh  walk  was  not  required,  and  the  sample  was  instead  tested  against 
each  triangle  in  the  cell.  Each  cell  was  guaranteed  to  have  at  least  one  triangle.  In  practice,  we  found 
that  this  approach  suffered  in  two  aspects.  Firstly,  it  was  costly  to  insert  the  triangles  into  the  data 
structure:  requiring  a  test  to  determine  all  of  the  quadtree  cells  that  the  triangle  intersected.  Secondly, 
we  found  it  difhcult  to  ensure  a  robust  implementation.  As  a  result  we  have  implemented  the  sample 
quadtree  structure  as  discussed  above. 

2.2.2  Testing  sample  quality 

Not  all  samples  are  added  to  the  mesh,  and  samples  may  be  deleted  from  the  mesh  as  the  result  of  tests 
performed  at  insertion  time  based  upon  the  density  and  quality  of  samples  in  the  mesh.  In  an  attempt 
to  minimize  artifacts  due  to  visibility  errors  from  approximate  sampling,  samples  are  also  rejected  once 
the  sampling  gets  relatively  dense  if  their  addition  would  cause  a  “puncture”  (e.g.  a  smooth  surface 
interrupted  by  a  single  sample  with  large  depth  discontinuity)  in  the  mesh. 

If  the  spherical  projection  of  two  samples  is  closer  than  some  dehned  resolution  epsilon,  £„ ,  only  one  of 
the  samples  will  ultimately  be  part  of  the  mesh.  We  choose  an  epsilon  corresponding  to  approximately 
0.028°  of  visual  angle  from  the  canonical  view.  This  is  done  both  to  avoid  instabilities  in  the  mesh 
construction  (see  Section  2.4)  but  also  because  it  corresponds  to  reasonable  rendering  resolution:  with 
a  60° (-I)  view  frustum  angle  and  a  screen  resolution  of  1024x1280  pixels,  there  are  approximately  19.35 
pixels/degree  (  measured  from  the  center  of  the  frustum  where  the  pixel/degree  ratio  is  densest).  A  mesh 
with  0.028°  or  .0005  radians  separation  between  samples  gives  approximately  1.8  samples  per  pixel.  A 
mesh  constructed  with  detail  beyond  this  would  not  add  signihcant  visual  information  to  the  hnal  image, 
but  would  incur  more  rendering  overhead.  We  therefore  choose  =  5  x  10“'^. 

To  determine  which  of  the  two  samples  to  keep,  we  hrst  examine  the  types  of  the  samples.  If  the  new 
sample  is  a  directional  point,  it  is  discarded:  it  is  assumed  that  foreground  points  are  always  preferable 
to  background  points,  so  if  the  new  sample  is  a  directional  sample  and  the  existing  one  is  a  world  space 
point,  the  new  sample  is  discarded;  if  both  the  existing  and  the  new  sample  are  directional  points,  they 
must  correspond  to  the  same  world  space  direction,  so  it  is  sufhcient  to  keep  the  existing  one  in  place. 
If  the  existing  point  is  a  directional  point  and  the  new  sample  is  a  world  space  point,  the  directional 
sample  is  replaced  with  the  foreground  sample.  If  both  samples  are  world  space  points,  we  compare  the 
sample  directions.  The  sample  that  was  calculated  from  the  direction  closest  to  the  direction  relative 
to  the  current  view  is  chosen.  This  is  based  on  the  assumption  that  a  sample  that  was  calculated  from 
a  view  direction  closer  to  the  current  view  is  less  likely  to  produce  a  visibility  error.  In  the  limit,  all  of 
the  samples  will  be  sent  from  the  current  view  and  there  will  be  no  visibility  errors  due  to  approximate 
sampling.  Let  be  the  direction  that  the  new  sample  was  calculated  from  and  Sg  the  sampled  direction 
of  the  existing  sample,  and  dn  and  dg  the  corresponding  directions  to  the  samples  from  the  current 
viewpoint:  if  {dg  ■  Sg)  >=  {dn  ■  Sn)  ,  the  existing  sample  is  considered  better  and  the  new  sample  is 
discarded.  If  the  opposite  is  true,  the  old  sample  is  deleted  from  the  mesh  and  the  new  sample  is  then 
added. 

For  efhciency,  the  test  occurs  after  point  location  has  been  performed  to  determine  which  mesh 
triangle  the  new  sample  falls  in.  The  sample  is  only  tested  against  the  three  vertices  of  the  triangle.  The 
actual  closest  sample  is  not  necessarily  one  of  these  three.  This  approximate  test  is  sufhcient  however, 
because  since  we  maintain  a  Delaunay  condition  on  our  mesh,  the  triangles  are  in  general  well-formed. 
The  only  way  that  a  vertex  outside  the  triangle  could  be  closer  is  if  there  was  a  long,  thin  triangle 
adjacent,  and  as  this  would  be  swapped  out  in  the  Delaunay  verihcation,  it  is  not  likely  to  happen.  We 
perform  a  conservative  test  to  eliminate  possibly  problematic  samples.  If  the  new  sample  falls  within  the 
circumcircle  (see  Section  2.2.3)  of  the  triangle,  there  cannot  be  any  vertex  closer  to  it  than  one  of  the 
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triangle  vertices  (by  definition,  no  other  samples  are  contained  in  the  circumcircle).  If  the  circumcircle 
test  fails,  the  new  sample  is  rejected.  In  practice,  this  situation  has  never  occurred. 

Due  to  the  re-use  of  samples,  the  re-projection  of  a  cached  sample  to  a  new  view  can  produce  incorrect 
visibility  results.  A  sample  that  was  visible  in  a  previous  view,  may  no  longer  be  visible  in  the  current 
view.  The  correct  sample  for  that  image  location  will  eventually  be  traced  and  replace  the  current 
sample  in  the  mesh,  but  right  after  a  view  motion  that  sample  may  not  yet  be  available.  In  this  case,  the 
old  sample  is  presented  by  the  driver  to  the  display  generation.  If  no  additional  checking  is  done,  this 
point  will  get  added  to  the  mesh,  and  can  create  the  artifact  of  false  “punctures”  in  the  mesh,  where  a 
continuous  foreground  surface  is  interrupted  by  a  sharp  depth  discontinuity  at  a  single  point.  With  small 
view  motions  this  artifact  is  most  likely  to  occur  near  object  silhouettes.  We  apply  a  simple  heuristic  to 
minimize  these  artifacts:  if  the  addition  of  a  sample  point  will  cause  a  sharp  depth  discontinuity  between 
the  new  point  and  its  neighbors,  and  the  new  point  is  behind  the  existing  points  relative  to  the  current 
view,  the  sample  is  not  added  to  the  mesh.  Note  that  such  a  puncture  point  could  be  valid:  for  example 
a  hue  screen  surface  in  front  of  a  background.  By  hrst  testing  the  direction  of  the  sample  to  see  if  it 
coincides  with  the  current  view,  we  can  differentiate  between  these  cases. 

When  we  are  inserting  a  sample,  we  must  also  check  if  there  is  room  in  the  existing  sample  array.  The 
array  is  hxed  in  size  at  initialization  time.  If  we  request  a  new  sample  and  determine  that  the  sample 
array  is  full,  we  must  hrst  delete  an  existing  sample  before  the  new  one  can  be  added.  We  choose  a 
simple,  approximate  Least  Recently  Used  (LRU)  sample  replacement  scheme.  Our  replacement  strategy 
is  based  on  a  clock  or  use  bit.  When  a  sample  is  hrst  allocated  its  use  bit  is  set.  At  rendering  time 
all  triangles  in  the  view  frustum  are  marked  as  active.  At  this  time  the  samples  corresponding  to  the 
adjacent  vertices  of  active  triangles  have  their  use  bits  set.  When  the  sample  array  is  full  a  circular 
traversal  is  made  from  the  location  of  the  last  allocated  sample.  The  traversal  visits  the  samples  in  the 
array  in  order,  testing  the  use  bits.  If  the  bit  is  set,  it  is  cleared,  and  the  traversal  moves  on  to  the 
next  sample.  If  the  bit  is  clear,  then  that  sample  is  chosen  for  removal  from  the  sample  array  and  the 
corresponding  vertex  is  removed  from  the  mesh.  With  this  algorithm,  samples  that  have  been  rendered 
recently  will  be  retained,  and  those  that  have  not  taken  part  in  the  most  recent  renderings  will  be  subject 
to  removal.  In  general,  the  size  of  the  sample  array  is  chosen  to  the  desired  screen  resolution,  so  it  is 
more  likely  that  samples  will  be  replaced  by  the  proximity  tests  as  described  at  the  beginning  of  this 
section  when  the  view  is  stationary.  If  the  user  is  moving  about,  the  mesh  will  be  periodically  rebuilt 
with  only  the  visible  samples  included.  In  an  interaction  scenario  where  the  user  spins  about  a  hxed 
viewpoint  and  pauses  at  various  locations,  enabling  the  progressive  rehnement  of  multiple  sections  of 
the  spherical  mesh,  it  is  possible  to  run  out  of  samples  in  the  array. 

If  the  sample  is  accepted,  the  triangle  is  subdivided  and  the  neighbors  are  updated  appropriately. 
If  the  triangle  falls  on  an  existing  sample,  it  will  be  handled  by  the  quality  testing  described  above. 
In  order  to  maintain  a  “well-behaved”  mesh  that  minimizes  rendering  artifacts  and  numerical  errors, 
we  maintain  a  Delaunay  condition  on  the  spherical  mesh  triangles.  This  is  discussed  in  the  following 
section. 

2.2.3  Delaunay  condition 

After  any  changes  to  the  mesh  topology,  a  test  is  performed  to  verify  if  the  Delaunay  condition  still 
holds.  A  triangle  satishes  the  Delaunay  condition  if  the  circumcircle  of  the  triangle  contains  no  other 
sample  points  [11].  In  two  dimensions,  this  condition  can  be  verihed  with  a  point-in-circle  test  (see 
Figure  7a). 

In  our  spherical  mesh  environment,  given  a  triangle  ti  with  vertices  vo,vi,  and  its  adjacent  neighbor 
tj  with  vertices  V2,vi,vs,  the  test  is  whether  vertex  1:3  lies  within  the  circumcone  formed  by  the  canonical 
viewpoint  and  vo,vi,V2  In  the  spherical  environment,  we  utilize  a  point-in-cone  test  (see  Figure  7b).  The 
triangle  vertices  vo,vi,V2  and  opposite  vertex  in  question  1:3  are  projected  onto  the  view  sphere  giving 
a,  b,  c,p.  A  point  p  lies  in  the  cone  dehned  by  the  canonical  viewpoint  and  a,  b,  c  if  the  angle  between  the 
cone  center  ray  z  and  p  is  less  than  the  angle  between  z  and  one  (any)  of  the  vertices  a,  b,  c  (see  Figure 


10 


Figure  7:  Delaunay  test:  a)  Point  in  circumcircle  test  in  the  plane  b)  Point  in  circumcone  test  in  spherical  environment 
c)  Vertices  are  projected  onto  the  sphere.  The  angle  between  the  cone  center  .s  and  the  point  in  question  p  is  compared 
against  the  radius  angle  of  the  cone  (e.g.  the  angle  between  .s  and  a) 


7c).  The  ray  z  defining  the  cone  center  is  equivalent  to  the  normal  to  the  plane  dehned  by  a,  b,  c.  The 
dot  product  of  any  normalized  point  p  and  z  is  proportional  to  the  cosine  of  the  angle  between  p  and 
the  cone  center  ray.  If  the  cosine  of  the  angle  between  z  and  p  is  greater  than  that  between  a  and  z,  the 
corresponding  angle  is  smaller,  and  p  lies  within  the  cone.  The  test  is  implemented  as  follows: 

z  =  {h  —  a)  X  {c  —  a) 
in  =  (p  •  z)  >  (a  •  z) 

After  the  addition  of  each  new  sample,  the  Delaunay  test  is  performed  against  the  sample  point  and 
all  adjacent  triangles.  If  the  test  fails,  an  edge  swap  is  performed  in  the  quadrilateral  formed  by  the  two 
adjacent  triangles  (see  Figure  8).  The  existing  triangles  are  deleted  and  two  new  triangles  formed  with 
the  neighbor  relationships  derived  from  the  previous  triangles.  These  new  triangles  are  then  added  to 
the  list  of  triangles  that  must  be  tested  against  their  neighbors  to  determine  if  the  Delaunay  condition 
is  maintained.  The  number  of  possible  swaps  performed  at  each  insertion  is  0{n)  for  a  mesh  with  n 
samples.  In  practice,  however,  we  have  found  the  number  of  edge  swaps  performed  per  sample  insertion 
is  2.8  on  average  over  a  number  of  representative  runs  of  the  mesh  generation. 


Figure  8:  Point  insertion:  a)  Point  Location  to  find  triangle  containing  p  b)  3  new  triangles  created  c)  New  triangle 
V0V1V2  with  point  vs  does  not  pass  circumcone  test  d)  After  swapping  2  edges  to  restore  Delaunay  condition 


The  Delaunay  test  is  performed  on  the  spherical  mesh  using  the  projection  of  the  3D  sample  coor¬ 
dinates.  This  projection  is  done  so  the  mesh  topology  can  be  constructed  more  efficiently  than  if  the 
problem  was  addressed  in  the  full  3D  space.  In  addition,  by  producing  a  mesh  that  is  Delaunay  when 
projected  from  the  canonical  view,  we  hope  to  generate  a  set  of  3D  triangles  that  will  be  less  susceptible 
to  shading  artifacts,  both  from  the  canonical  viewpoint  and  from  neighboring  locations.  It  is  important 
to  remember  that  the  world-space  coordinates  are  actually  utilized  as  the  mesh  vertices.  This  allows 
the  re-use  of  the  mesh  from  viewpoints  slightly  off  the  canonical  view  simply  by  having  the  rendering 
hardware  do  the  appropriate  transformations  upon  the  3D  triangles. 
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2.3  Sample  Deletion 

It  is  possible  for  samples  to  be  deleted  from  as  well  as  inserted  into  the  mesh.  Samples  are  deleted  by 
marking  the  sample  as  free,  removing  all  adjacent  triangles,  re-triangulating  the  hole,  and  re-asserting 
the  Delaunay  condition  (see  Figure  9  for  an  example  in  the  plane).  We  discuss  relevant  details  below. 

After  the  adjacent  triangles  have  been  deleted,  the  chain  of  edges  forming  the  boundary  of  the  hole  is 
constructed  by  traversing  the  neighbors  counterclockwise  until  all  adjacent  triangles  have  been  visited. 
The  resulting  spherical  polygon  is  then  re-triangulated.  This  is  not  a  general  triangulation  routine,  as 
we  are  able  to  exploit  the  fact  that  the  spherical  polygon  formed  by  the  removal  of  the  vertex  p  from  the 
mesh  is  a  star  relative  to  p.  The  re-triangulation  proceeds  by  traversing  the  boundary  list  and  cutting  off 
ears  formed  by  a  consecutive  triple  of  vertices  sq,  si,  S2-  A  cut  is  is  accepted  iff  the  following  conditions 
are  true: 

1.  The  edge  S2S0  does  not  intersect  any  boundary  edges  of  the  remaining  spherical  polygon. 

2.  The  angle  formed  by  soSiS2  is  less  than  tt  (i.e.  convex). 

3.  The  resulting  new  triangle  passes  the  Delaunay  test  (i.e.  none  of  the  remaining  vertices  of  the 
spherical  polygon  lie  in  the  cone  dehned  by  soSiS2  and  the  canonical  view  point). 

The  Delaunay  condition  (3)  guarantees  that  no  edge  intersections  occur,  but  the  implementation  of 
the  Delaunay  test  is  more  expensive  than  the  intersection  test  (1),  and  the  convexity  test  (2)  can  use 
the  results  of  this  test,  so  it  is  implemented  as  constraint  1.  The  resulting  triangulation,  due  to  the  3rd 
constraint,  satishes  the  Delaunay  condition  on  the  sphere. 


Figure  9:  Sample  Deletion  in  the  plane:  a)  Initial  mesh  b)  Adjacent  triangles  are  deleted,  creating  a  hole  c)  Re- 
triangulation  of  hole  with  Delaunay  condition  asserted 


Given  the  projection  of  a  sequential  triple  of  vertices,  sq;  si;  S2)  onto  the  view  sphere,  we  hrst  perform 
the  test  for  edge  intersection.  To  determine  if  any  intersecting  edges  would  result,  a  test  is  performed 
to  hud  which  side  of  the  new  edge  the  original  (deleted)  center  sample  lies  on.  Because  the  initial 
conhguration  was  a  star  formation  around  the  center  vertex,  an  edge  formed  between  two  vertices  that 
forms  a  polygon  disjoint  from  the  one  containing  the  center  point  cannot  intersect  any  other  edges. 

The  implementation  of  the  test  calculates  the  normal  to  the  plane  of  the  great  circle  dehning  the 
spherical  edge  S2So'.  n  =  sq  x  82-  If  the  center  point  p  lies  outside  of  this  edge,  the  edge  cannot  intersect 
any  of  the  remaining  edges  in  the  spherical  polygon.  This  can  be  determined  by  taking  the  dot  product 
with  the  projected  point  p  with  the  resulting  cross  product  (see  Figure  fOa).  The  sign  of  the  dot  product 
determines  which  case  is  true:  The  test  is  calculated  as  t  =  {n  ■  p)  where  p  is  the  deleted  sample.  If  t  is 
positive,  the  center  point  lies  on  the  inside  of  the  proposed  triangle,  and  the  triple  is  rejected  (see  Figure 
10b).  If  the  test  passes,  the  test  for  convexity  is  next  performed.  If  the  remaining  spherical  vertex  si 
lies  in  the  negative  half-space  dehned  by  n,  the  angle  is  convex. 

Finally  the  Delaunay  condition  is  tested.  Each  remaining  point  on  the  spherical  polygon  boundary 
is  tested  for  inclusion  in  the  cone  dehned  by  S0)Si)S2  and  the  canonical  viewpoint  (see  Section  2.2.3). 
If  no  point  lies  within  the  cone,  then  the  cut  is  accepted.  Points  outside  of  the  boundary  need  not  be 
tested. 
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Figure  10:  Re-triangulation  after  deletion  a)  Bounding  spherical  polygon  after  deletion  of  sample  projected  as  p.  Angle 
S0S1S2  is  convex,  and  S1S2S3  concave  relative  to  the  spherical  polygon  interior.  Great  circle  normals  are  shown,  b)  Testing 
edge  S2S0  point  p  lies  to  the  outside  of  the  triangle  S0S1S2  and  the  Delaunay  condition  is  upheld,  so  the  split  is  accepted. 


Once  all  convex  angles  have  been  trimmed  off  as  triangles,  a  single  triangle  or  a  spherical  quadrilateral 
will  remain  (it  can  have  more  than  four  edges,  but  those  additional  edges  are  coincident  with  the  same 
great  circle).  If  the  remaining  polygon  is  a  triangle,  the  triangulation  is  complete.  If  the  polygon  is  a 
quadrilateral,  a  trivial  triangulation  is  performed. 

2.4  Robustness 

It  is  very  important  for  our  application  that  the  incremental  mesh  construction  be  fast.  It  also  must 
be  robust,  however.  We  accomplish  this  through  a  combination  of  performing  inexact  tests  wherever 
possible,  and  imposing  constraints  on  the  mesh  based  on  the  input  and  computing  environment  to  ensure 
that  round-off  error  is  not  a  problem.  We  also  take  advantage  of  the  fact  that  we  do  not  need  to  add 
every  sample.  Those  for  which  we  cannot  make  guarantees  about  the  resulting  mesh  are  discarded.  As 
this  happens  very  infrequently,  and  only  when  the  sampling  is  dense,  no  adverse  effects  are  observed. 

The  algorithms  manipulating  the  mesh  depend  on  a  clean  2D  topology.  In  our  context  this  means 
that  the  mesh  elements  only  intersect  at  mesh  vertices,  and  each  edge  is  adjacent  to  exactly  two  triangles. 
For  efficiency  purposes,  there  are  no  run-time  tests  to  detect  corrupted  topology;  we  instead  ensure  clean 
topology  by  construction.  There  are  two  major  geometric  operations  involved  in  mesh  construction  : 
point  location,  and  testing  for  the  Delaunay  condition.  In  this  section  we  discuss  an  implementation  of 
each  geometric  operation  that  produces  clean  mesh  topology  at  each  step. 

In  the  following,  edge  lengths  are  represented  by  the  angle  measured  in  radians  subtended  by  the  two 
spherical  end  points.  Angles  interior  to  the  triangle  are  measured  as  the  angle  between  the  two  planes 
defined  by  the  great  circles  associated  with  the  spherical  edges. 

2.4.1  Point  Location 

The  primary  and  most  expensive  task  in  mesh  construction  is  point  location:  given  a  new  spherical  point, 
we  must  determine  which  existing  triangle  the  point  falls  in.  We  first  utilize  the  spherical  quadtree  to 
put  us  in  the  neighborhood  of  the  triangle.  We  then  initiate  a  walk  to  find  the  correct  triangle.  We  do 
not  require  that  the  spherical  quadtree  data  structure  be  completely  robust:  due  to  round-off  error,  a 
sample  near  a  cell  boundary  could  be  inserted  into  a  cell  adjacent  to  its  correct  location.  This  sort  of 
inconsistency  is  tolerated  for  efficiency  at  insertion  time,  and  because  it  does  not  lead  to  catastrophic 
topology  errors.  If  the  walk  starts  in  the  incorrect,  nearby  cell,  this  error  will  at  most  degrade  the 
efficiency  slightly;  even  in  the  case  where  a  point  has  been  inserted  exactly,  the  search  is  often  started 
only  in  the  neighborhood  of  the  correct  triangle.  In  order  that  this  inconsistency  in  the  point  location 
not  cause  problems  when  searching  for  specific  points  to  remove  from  the  data  structure  during  sample 
deletion,  each  sample  maintains  a  pointer  to  its  quadtree  cell,  so  it  can  be  removed  directly  without  a 
traversal. 
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Figure  11:  Round-ofF  error  can  lead  to  the  invalid  topology  in  the  middle  figure  if  the  orientation  test  reports  that  the 
point  is  on  the  right  side  of  the  edge.  An  edge  split  would  produce  the  valid  construction  shown  in  the  right  figure,  fn 
both  examples,  the  new  edges  are  shown  in  solid  line,  and  the  edges  retained  from  the  previous  configuration  are  shown 
dotted. 


During  the  walk,  we  compare  the  edges  of  the  current  triangle  to  the  point,  to  determine  if  the  point 
lies  interior  to  the  triangle,  and  if  not,  which  edge  to  cross  to  continue  the  walk.  Problems  can  occur 
when  a  point  is  close  to  one  or  more  edges.  Figure  11  illustrates  one  potential  problem.  In  the  left 
hgure,  the  round-off  error  is  such  that  the  test  determines  that  the  point  is  on  the  right  side  of  the 
edge,  incorrectly  splitting  the  triangle,  resulting  in  the  topology  shown  in  the  middle  hgure.  To  prevent 
this  problem,  if  a  point  is  within  some  epsilon,  eg,  of  an  edge,  it  is  treated  as  if  it  is  on  the  edge  and  a 
four- way  split  is  performed  on  the  two  adjacent  triangles.  The  result  is  shown  in  the  right  hgure. 


Figure  12:  ff  ce  is  too  large  and  adjacent  edges  overlap,  the  wrong  edge  can  be  split  as  shown  in  the  top  figure.  Invalid 
topology  can  also  occur  with  too  large  values,  as  shown  in  the  bottom  figure,  even  if  the  e  regions  do  not  overlap.  We 
choose  Ce  to  be  less  than  edge  separation  for  the  smallest  angle  a  a  distance  ty  from  the  vertex  as  shown  in  the  lower  right 
figure 


The  next  example  in  Figure  12  illustrates  topological  errors  that  can  occur  if  eg  is  chosen  too  large. 
The  point  p  is  within  Cg  of  two  edges  {ha  and  ch).  If  the  edge  ha  is  tested  hrst,  then  the  topological  error 
shown  in  the  middle  hgure  will  occur  if  the  two  triangles  are  split  into  four.  The  desired  answer  is  shown 
on  the  right.  Finding  the  closest  edge  within  eg  would  avoid  this  error,  but  we  would  prefer  not  to  have 
to  test  for  this.  Instead  we  choose  eg  small  enough  such  that  a  point  cannot  be  within  Cg  of  more  than 
one  edge.  Lastly,  the  bottom  of  Figure  12  shows  another  potential  problem  if  Cg  is  chosen  too  large.  The 
split  is  shown  in  the  adjacent  hgure.  The  split  causes  invalid  topology  because  Cg  is  larger  than  the  edge 
separation  for  the  smallest  angle,  a  distance  £„  away  from  the  vertex  (cy  is  the  minimum  angle  distance 
between  vertices  and  therefore  the  minimum  edge  angle) .  We  choose  eg  <  |  to  avoid  this  kind  of  error 
(see  lower  right  Figure  12). 

We  hrst  utilize  constraints  on  our  environment  to  determine  what  Cg  to  choose  such  that  the  above 
problems  cannot  occur.  This  analysis  assumes  that  calculations  are  done  with  exact  arithmetic.  We  then 
do  forward  error  analysis  on  the  angle  calculation  code  to  make  sure  that  round-off  errors  in  the  machine 
arithmetic  calculations  are  not  large  enough  to  introduce  inconsistencies  given  our  chosen  constraints. 
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2.4.2  Selecting  Epsilon 

We  choose  eg  <  f ,  where  d  is  the  angle  separation  between  two  spherical  edges,  a  distance  £„  away  from 
the  vertex.  We  can  calculate  a  lower  bound  on  this  distance  d,  given  the  initial  mesh  and  the  constraints 
imposed  by  the  triangulation  algorithm. 

The  initial  base  triangulation  is  an  icosahedral  subdivision  of  the  sphere.  An  icosahedron  can  be 
constructed  from  three  mutually  perpendicular  golden  rectangles,  i.e.  rectangles  whose  length  and  width 
are  related  by  the  golden  ratio  ip  «  1.61803.  ^  This  is  illustrated  in  Figure  13.  The  initial  spherical  edge 
length  is  «  1.10715. 


P2  =  (0(p/2,-l/2) 


p„=  (0,<p/2,l/2) 


Figure  13:  Icosahedron  construction  and  edge  angle 


The  initial  triangulation  dehnes  the  largest  circumcone  that  can  exist  in  the  mesh.  Let  a,b,c  be 
the  spherical  points  corresponding  to  po,pi,P2-  We  can  calculate  the  center  ray  of  this  cone,  z,  as  the 
normal  to  the  spherical  triangle:  z  =  .  The  cone  radius  angle  6  =  cos~^[z  ■  a)  «  0.652358. 

This  is  illustrated  on  the  left  in  Figure  14. 


Figure  14:  Calculating 


minimum  (o)  and  maximum  (7)  possible  angle  bounds  for  the  spherical  mesh 


In  the  mesh  construction,  no  two  points  are  allowed  to  be  closer  than  Cy ,  therefore  the  minimum 
edge  length  possible  is  (f)  =  £y.  Given  these  bounds,  we  can  calculate  the  minimum  possible  angle.  The 
minimum  angle  occurs  for  a  triangle  with  circumcone  of  radius  9,  and  two  edges  of  length  (f)  (see  Figure 
14).  Given  (j)  =  Cy  =  b  x  (see  Section  2.2.2  ),  we  calculate  the  maximum  angle  7  (a  = 

For  this  calculation,  we  choose  the  cone  axis  to  be  z  =  (0.0,  0.0,  1.0),  and  choose  =  0.0.  We  can 
solve  for  r,  s  based  on  the  following  constraints: 

r  ■  z  =  cos  6  s-z  =  cos9  ||r||=||s||  =  l  r  ■  s  =  cos  (f) 

r  =  (0.0,  sin  6*,  cos  6*)  .Sy=cos0  Sj,  =  .^1.0  - 

Given  r,  s  we  can  calculate  the  maximum  angle  7  and  minimum  angle  a: 


^The  golden  ratio  is  the  value  of  x  such  that  y  =  . 


Choosing  the  positive  root,  ip  =  x  = 


i+vTs) 

2 


1.61803 


15 


7  =  2  cos 


1 


3.140938 


a  =  0.000327 

Given  the  minimum  and  maximum  angles,  we  can  calculate  what  the  minimum  edge  separation  d 
is,  a  distance  (f)  from  the  vertex  forming  the  minimum  angle.  We  will  assign  eg  =  |.  Again,  looking  at 
Figure  14,  we  wish  to  calculate  cr.  We  use  the  following  constraints  to  hrst  calculate  t,  then  the  halfway 
vector  v: 

r  =  (0.0,  0.0,  1.0)  r-s  =  cos(()  r-t  = 
ty  =  1  —  cos^  (f)  =  sin^  (f)  sin  7  = 

From  the  resulting  value  of  t  (see  Appendix  B),  we  calculate  the  halfway  vector  v  between  s,t.  The 
result  of  t;  •  r  is  the  cosine  of  the  minimum  edge  separation.  Since  r  =  (0,  0,  1),  cos  cr  =  r  ■  v  =  = 
9.9999  X  10“^  and  the  minimum  angle  a  =  1.056  x  10“^.  We  choose  the  edge  epsilon  to  be  less  than 
half  the  value  ofcr:  ee  =  5xl0“®.  The  following  section  evaluates  the  possible  effects  of  round-off  error 
from  utilizing  inexact  arithmetic  to  perform  the  angle  calculation. 

Mesh  topology  is  also  altered  in  order  to  maintain  the  Delaunay  condition.  We  must  ensure  that  the 
mesh  remains  topologically  sound  through  these  operations  as  well.  We  verify  in  the  Section  2.4.4  that 
the  algorithm  described  in  this  section  also  satishes  the  constraints  of  the  Delaunay  predicate. 

2.4.3  Forward  Error  Analysis 

In  this  section,  we  analyze  the  possible  round-off  error  that  could  be  incurred  in  the  angle  calculation. 
This  value  must  not  be  signihcant  enough  to  cause  problems  based  on  the  given  choices  of  Cg  and 
We  apply  forward  error  analysis  [12]  to  derive  error  bounds  for  the  angle  calculation.  In  the  following,  ti 
refers  to  the  true  value  of  sub-computation  i,  and  Xi  is  the  computed  value  of  that  calculation  including 
cumulative  round-off  error.  In  the  IEEE  standard  for  binary  floating  point  arithmetic  (ANSI/IEEE 
754-1985)  [4],  a  floating  point  calculation  with  exact  round-off  can  be  in  error  as  much  as  i  units  in  the 
last  place  (nip).  With  base  /3  =  2,  and  p-bit  signihcand,  the  error  in  rounding  t  to  x  =  d.dd  ...(7x2'^  is 

p 

<  p.OO  .  .  . 0^1  X  2®  =  e  X  2®.  For  double  precision  floating  point  the  machine  epsilon,  e  =  2“®®.  Therefore: 

p 


cos  (p  I  |s|  I  = 

(s  — r)  X  jt  —  r) 


t  =1 


=  (0, 


i<p) 


1^  “  <  2“^^  <  e  X  2®  <  €\x\ 

In  the  error  analysis,  we  use  the  following  upper  bound  on  the  round-off  error: 

t  =  X  ±  e\x\ 

In  the  following,  the  symbols  (B,  Q,  0,  SQRT  represent  double  floating  point  addition,  subtrac¬ 
tion,  multiplication, division,  and  square  root  with  exact  rounding.  For  the  above  operations,  the  IEEE 
standard  requires  the  answer  to  be  exactly  rounded:  therefore,  with  ©  representing  the  stated  binary 
operations,  we  use  the  following  expression  of  the  error  analysis: 

t  =  a  Q  h  ±  £\a  Q  h\ 

For  square  root,  t  =  SQRT[a)  ±  eSQRT[a) . 

For  addition/subtraction  of  two  terms  {x±a)  and  (t/±/3),  where  x,  y  are  the  calculated  subcomponents 
and  a,l3  the  accumulated  error,  the  true  value  t  is: 
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t  =  x-\-y±{a-\-j3)  =  x®y±  {e\x  ©  t/|  +  a  +  /3) 


Similarly  for  multiplication  of  two  terms  {x  ±  a)(t/  ±  /3): 


t  =  xy  ±  [aj3  +  xj3  +  ya)  =  x  ®  y  ±  (ej*  ®  t/|  +  a/3  +  xj3  +  ya) 
For  square  root  (see  Appendix  C.l): 


t  =  SQRT{x)  ±{€\SQRT{x)\-\-^\ax  ^\  +  +^\a^x  = 
For  division  of  terms  {x  ±  a)  and  {y  ±  [3)  (see  Appendix  C.2): 
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For  spherical  edge  ah  and  normalized  point  p,  we  want  to  calculate  the  angle  between  ah  and  p.  We 
hrst  calculate  the  normal  to  the  great  circle,  or  plane  through  a,  h  and  the  origin,  n  =  For  9,  the 

angle  between  the  normal  and  the  ray  to  the  point,  {n  ■  p)  =  cos6.  The  calculations  can  be  represented 
as  follows: 
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We  now  derive  a  bounds  for  the  worse  case  error.  Since  the  input  points  lie  on  the  unit  sphere, 
|aj;|,  Iflyl,  |a^|,  l&yl,  l&^l,  |cj;|,  |cj,|,  |c^|  <=  T  The  magnitude  of  the  cross-product  is  equal  to  sin/?, 
where  6  is  the  edge  length.  We  can  bound  this  value  (|*i5|,  and  its  square  root  |*i4|)  given  the  initial, 
and  minimum  edge  lengths:  2.5e  —  7  <  |*i4|  <  .930856  and  5e  —  4  <  \xi^\  <  .96480899 

Given  these  upper  bounds,  we  calculate  the  error  by  implementing  the  above  forward  error  calcula¬ 
tions  using  a  multi-precision  arithmetic  package  (MPFUN  [1])  and  giving  the  bounded  values  as  input. 
Given  this  approximation  the  upper  bound  on  the  round-off  error,  <=  1.1  x  10“^^. 

A  change  in  cosO,  (i(cos/?)  =  1.1  x  10“^^  when  6  Ki  corresponds  approximately  to  a  linear  change 
in  0,  56  K,  1.1  X  10“^^.  Since  this  value  is  well  within  our  choice  of  the  test  will  not  be  troubled  by 
round-off  error.  The  forward  error  analysis  was  a  conservative  estimate.  We  calculate  the  round-off  error 
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Table  1:  Round-off  Error:  Experimental  Results 


Test 

Minimum 

Maximum 

Average 

Std.  deviation  cr  =  -^ ”  ^ 

Orientation 

0.0 

5.15  X  10-1® 

1.86  X  10-23 

1.8  X  10-21 

Point-in-Cone 

0.0 

1.75  X  10-1® 

1.5  X  10-24 

5.09  X  10-22 

over  various  runs  of  the  program,  by  comparing  the  computed  value  to  that  calculated  using  MPEUN. 
Approximately  500,000  angle  calculations  were  performed  each  run.  A  small  portion  of  the  screen  was 
selected  for  progressive  rehnement  during  the  course  of  the  run  in  order  that  the  mesh  reached  maximum 
density  during  the  test.  The  results  from  this  test  are  shown  in  Table  1  in  the  row  labeled  “Orientation” . 


2.4.4  Delaunay  predicate 


Eor  the  Delaunay  point-in-cone  test,  for  triangle  a,b,c  and  point  p,  we  calculate  the  center  axis  z  of 
the  cone  circumscribing  triangle  a,  b,  c  (see  Eigure  7):  z  =  {b  —  a)  x  {c  —  a)  To  test  if  p  lies  within  the 
cone,  we  compare  the  cosines  of  the  angle  between  p  and  a,  and  the  cone  axis,  z.  If  p  lies  within  the 
cone,  (p  •  z)  >  (a  •  v)  Eigure  15  shows  a  potential  problem  that  could  occur  due  to  round-off  error.  If 
cumulative  error  in  the  calculation  causes  the  test  to  return  true  in  the  situation  illustrated  in  Eigure  15a, 
the  invalid  topology  shown  in  Eigure  15b  will  occur  after  the  edge  flip.  When  the  triangle  interior  angles 
are  very  large(small),  the  magnitude  of  z  approaches  zero.  We  have  shown  that  the  maximum  angle 
7  «  3.140938,  with  sin  7  «  6.5  x  10“'^. Since  the  minimum  edge  separation  between  a,p  is  £„  =  5  x  10“'^, 
the  round-off  error  in  the  dot  product  calculation  would  need  to  be  greater  than  ^  =  2.5  x  10“'^  to  cause 
problems.  Our  worst  case  analysis  (see  previous  section)  yields  a  round-off  error  of  <  2.5  x  10“^®. 
Run-time  calculations  produce  the  round-off  errors  shown  in  the  second  row  of  Table  1. 


Eigure  15:  Delaunay  test  errors 


We  must  also  address  the  degenerate  case  where  all  four  points  a,  b,  c,plie  on  a  circle  (see  Eigure  15c). 
Depending  on  the  algorithm,  in  this  instance  the  Delaunay  test  could  go  into  an  inhnite  loop,  repeatedly 
flipping  the  diagonal  of  the  quadrilateral  formed  by  a,b,c,p.  We  address  this  case  algorithmically.  All 
swaps  are  initiated  by  the  addition  of  a  new  vertex  a.  The  test  is  performed  always  using  the  triangle 
a,b,c,  for  each  triangle  adjacent  to  a,  to  form  the  circumcone,  and  p  is  the  remaining  point  in  the  opposite 
triangle  pcb.  In  the  degenerate  case,  the  flip  will  only  occur  once,  each  time  a,  &,  c  or  p  is  manipulated. 


3  Rendering 

One  of  the  advantages  of  the  spherical  mesh  display  representation  is  that  it  is  a  valid  3D  triangle  mesh 
that  can  be  transformed  with  new  views  and  rendered  directly  by  the  hardware  using  OpenGL.  After 
each  view  change,  the  current  mesh  is  Rrst  rendered.  As  more  sample  points  are  received  for  the  same 
view,  the  mesh  and  the  display  are  incrementally  updated.  The  mesh  constructed  from  a  canonical 
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viewpoint  is  valid  for  all  viewing  configurations  with  the  same  eye  position.  For  small  view  motions 
relative  to  the  distance  to  the  viewed  sample  points,  the  mesh  is  re-used.  With  this  approximation, 
errors  will  appear  in  the  image  where  portions  of  the  environment  are  occluded  relative  to  the  canonical 
viewpoint,  but  visible  to  the  current  eye  point  (or  vice  versa).  We  minimize  these  errors  by  constructing 
a  new  mesh  once  the  viewer  moves  a  substantial  distance  away  from  the  canonical  viewpoint. 

In  Section  3.1  we  hrst  describe  how  the  mesh  is  rendered  for  a  single  view,  and  how  view  frustum 
culling  is  utilized  to  optimize  the  rendering  performance.  We  then  describe  how  the  rendering  algorithm 
handles  the  following  interaction  scenarios: 

•  The  observer  is  stationary,  and  new  samples  are  being  generated  (Incremental  Rendering,  Section 
3.2). 

•  The  viewer  is  moving  (Rendering  During  View  Motion,  Section  3.4). 

•  The  viewer  has  moved  a  substantial  distance  away  from  the  canonical  viewpoint  (Mesh  Rebuilding, 
Section  3.5). 

3.1  Basic  Rendering  Algorithm 

Because  the  representation  is  a  triangle  mesh  with  world  space  coordinates  and  RGB  color  values  for  all 
vertices,  for  the  most  part  rendering  is  very  straightforward  using  OpenGL.  Points  at  inhnity,  if  they  are 
present,  must  be  handled  separately.  A  point  at  inhnity  comes  in  from  the  driver  as  a  direction  vector. 
This  is  represented  as  a  directional  point  in  the  mesh  by  adding  the  canonical  viewpoint  to  the  direction 
vector  and  creating  a  point  on  the  view  sphere.  This  mesh  point  can  then  be  treated  identically  to  the 
world  space  samples  for  mesh  manipulation.  For  rendering,  the  directional  points  are  processed  hrst. 
The  depth  buffer  is  disabled,  and  all  triangles  made  up  entirely  of  directional  points  are  translated  to  the 
origin,  scaled  if  necessary  to  ensure  they  are  not  clipped  to  the  frustum,  and  then  translated  relative  to 
the  current  view  point.  If  a  triangle  is  “mixed”,  or  contains  one  or  two  directional  points,  it  is  processed 
with  the  background  triangles.  The  world  space  points  are  projected  onto  the  current  view  sphere,  and 
then  scaled  if  necessary  to  ht  in  the  frustum. 

Once  all  background  triangles  are  rendered,  depth  testing  is  enabled  and  the  remaining  triangles 
are  rendered  in  the  standard  way.  The  only  other  consideration  is  the  handling  of  base  points.  These 
resemble  a  directional  point  in  that  they  are  stored  as  a  unit  vector  relative  to  the  canonical  viewpoint. 
They  do  not  have  a  valid  RGB  value.  If  a  base  point  is  part  of  a  background  triangle,  its  coordinate 
is  rendered  as  a  background  point  would  be.  For  a  foreground  triangle,  the  direction  vector  is  scaled 
out  by  the  average  distance  to  the  foreground  points  from  the  current  view.  For  both  foreground  and 
background  triangles  the  color  used  is  the  average  of  the  non-base  vertices  of  the  triangle. 

3.2  Incremental  Rendering 

When  the  observer  is  stationary,  and  new  samples  are  being  generated,  incremental  updates  are  made  to 
the  mesh  and  to  the  display.  Each  batch  of  new  triangles  will  overwrite  the  image  of  the  parent  triangles. 
We  utilize  a  painter’s  approach  in  the  incremental  display  algorithm:  the  depth  buffer  is  disabled,  the 
new  triangles  are  depth-sorted,  then  rendered  back-to-front.  As  in  the  general  case,  background  and 
mixed  triangles  are  rendered  hrst,  then  foreground  triangles.  When  the  canonical  viewpoint  corresponds 
to  the  current  eye  point,  depth  testing  is  unnecessary  (and  not  performed),  but  as  we  will  discuss  below, 
these  two  points  do  not  always  coincide. 

3.3  View  Frustum  Culling 

To  optimize  rendering  and  mesh  reconstruction,  we  utilize  the  spherical  quadtree  data  structure  to 
perform  view  frustum  culling.  Each  of  the  6  faces  of  the  view  frustum  is  split  into  two  triangles  (see 
Figure  16a).  All  nodes  of  the  spherical  quadtree  that  the  projection  of  a  frustum  triangle  overlaps 
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are  marked.  All  samples  stored  in  the  marked  nodes,  and  all  triangles  adjacent  to  those  samples,  are 
considered  visible. 


Figure  16:  View  Frustum  culling  a)  Frustum  divided  into  triangular  facets  b)  Clipping  frustum  triangles  against  the 
octants  c)  When  viewpoint  coincides  with  canonical  viewpoint:  Only  the  front  frustum  face  needs  to  be  inserted  d)  When 
the  viewpoint  is  inside  the  view  frustum,  the  projection  encompasses  the  whole  frustum  and  does  not  help. 


The  frustum  culling  is  implemented  utilizing  the  spherical  quadtree.  Each  quadtree  root  that  a 
frustum  triangle  overlaps  is  traversed.  At  each  level,  the  child  branches  are  visited  for  those  children 
that  the  triangle  cannot  be  trivially  rejected  as  not  intersecting  that  node.  At  the  leaf  level,  a  triangle- 
triangle  test  is  performed.  All  samples,  and  their  adjacent  triangles,  contained  in  any  cell  that  the 
triangle  intersects  are  marked  as  visible.  For  each  quadtree  root  that  the  frustum  triangle’s  projection 
intersects,  the  frustum  triangle  must  be  clipped  against  the  planes  forming  the  quadtree  root. 

The  clipping  proceeds  by  clipping  the  initial  triangle  against  each  of  the  coordinate  planes.  A  list  of 
vertices  is  maintained:  one  for  those  that  fall  above  the  plane  and  one  for  those  that  fall  below  it.  Since 
we  are  testing  against  the  coordinate=0  plane,  the  intersection  test  is  trivial.  Starting  with  the  hrst 
plane,  for  example  x=0,  we  test  each  triangle  edge  against  the  plane.  We  form  two  lists,  those  vertices 
that  lie  below  the  plane  (i.e.  p[0]  <  0.0)  and  those  that  lie  above  it  (i.e.  p[0]  >  0.0).  Points  that  lie 
on  the  plane  are  added  to  each  list.  Where  an  edge  spans  the  plane,  the  intersection  is  found  (again 
an  easy  computation  since  we  are  dealing  with  coordinate  planes).  This  point  is  added  to  each  list  (see 
Figure  16b).  After  the  hrst  set  of  tests,  at  most  two  convex  polygons  are  formed.  The  tests  with  the 
next  coordinate  plane  are  then  performed  on  these  polygons. 

After  the  intersection  tests,  we  will  have  a  maximum  of  8  vertex  lists,  each  comprising  a  convex 
polygon.  Each  of  these  lists  is  trivially  triangulated  by  forming  a  triangle  from  every  sequential  triple 
of  vertices.  The  resulting  triangles  are  then  processed  by  the  insertion  algorithm. 

For  each  quadtree  root,  we  hrst  convert  the  projected  triangle  to  barycentric  coordinates.  We  traverse 
to  the  leaf  levels,  following  each  child  path  where  we  cannot  perform  a  trivial  reject.  At  each  level  we  pass 
down  the  barycentric  coordinates  of  the  current  quadtree  node,  the  triangle  barycentric  coordinates,  and 
a  scale  value.  The  coordinates  of  the  node  are  calculated  at  each  level  from  the  parent’s  coordinates, 
the  child  number,  and  the  scale  value.  The  triangle  vertex  coordinates  remain  unchanged  for  better 
numerical  stability.  We  determine  what  children  the  triangle  could  possibly  intersect  by  a  simple  test. 
If  all  three  vertex  coordinates  have  hrst  coordinates  greater  than  a,  for  example,  the  triangle  must  lie  in 
the  zeroth  child.  If  this  is  not  the  case  for  any  of  the  sides  a,b,  or  c,  we  then  check  to  see  if  the  vertices 
are  outside  all  edges  (less  than),  indicating  that  it  must  lie  entirely  in  child  3.  Otherwise,  the  traversal 
continues  down  any  child  path  that  has  any  vertex  in  its  positive  space.  The  procedure  requires  at  most 
3  additions,  3  shifts,  and  9  compares  at  each  level.  Figure  17  includes  an  explanation  of  the  variables 
and  an  example.  Note  that  in  the  example  floating  point  values  are  used  for  expository  purposes.  The 
variables  sa,  sh,  sc  store  the  result  of  the  test  against  each  half-space  respectively  for  each  vertex  tO,  tl,  t2. 

In  the  case  where  the  traversal  continues  down  the  middle  child,  child  3,  the  orientation  of  the  triangle 
reverses  with  respect  to  a,b,c.  (see  Figure  17d).  The  maximum  barycentric  value  for  a  coordinate  is  no 
longer  at  the  vertex,  but  on  the  opposite  edge.  While  traversing  such  a  branch,  the  testing  operations 
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Figure  17:  Triangle  intersection.  Shaded  triangles  indicate  children  visited  on  traversal  a)  Triangle  t  and  its  barycentric 
coordinates  relative  to  quadtree  root  q.  b)  At  first  level,  child  0  does  not  need  to  be  traversed,  c)  Child  1  at  level  2:  all 
children  are  traversed:  Note  that  triangle  does  not  intersect  child  1  but  this  is  not  revealed  by  trivial  reject  test,  d)  Child 
3  at  level  2:  all  children  must  be  traversed  e)  Child  2  at  level  2:  Child  2  can  be  rejected  f)  Resulting  set  of  cells  after 
triangle-triangle  test  performed  at  leaf  level. 


must  be  adapted  accordingly:  addition  turns  to  subtraction,  and  the  greater-than  test  is  replaced  with 
a  less-than  test. 

By  the  time  that  we  have  reached  a  leaf  node,  we  have  determined  only  that  the  triangle  could 
not  be  trivially  rejected.  To  determine  if  the  triangle  does  indeed  intersect  the  cell  we  must  perform 
a  dehnitive  intersection  test  between  the  triangle  and  the  quadtree  cell  at  the  leaf.  To  perform  this 
test  efhciently  we  maintain  the  information  about  the  relative  position  of  the  vertices  calculated  in  the 
previous  steps  during  the  traversal.  We  hrst  check  if  the  triangle  can  be  trivially  accepted.  This  is  true 
if  any  of  the  triangle  vertices  lie  in  the  cell.  This  is  implemented  as  a  bitwise  AND:  (sa&s&fesc)  and 
will  be  nonzero  if  any  vertex  lies  in  the  cell.  If  no  vertex  lies  in  the  cell,  we  next  attempt  to  see  if  the 
triangle  can  be  accepted  if  any  of  the  vertices  lie  ON  a  cell  edge,  giving  a  conservative  answer:  if  the 
triangle  is  just  touching  the  cell  it  will  be  considered  as  IN.  This  will  be  true  if  for  any  of  the  vertices, 
t;[0]  =  qa,v[l]  =  qh,  or  v[2]  =  qc.  (see  Figure  18). 

If  the  triangle  cannot  be  trivially  accepted,  we  then  test  for  edge  crossings.  We  hrst  test  if  the  edge 
can  be  trivially  rejected  from  crossing  using  the  bits  calculated  earlier.  If  both  vertices  on  the  triangle 
edge  lie  to  one  side  of  the  line  dehning  the  quadtree  edge,  no  intersection  test  is  necessary.  We  also  test 
against  the  3  lines,  bounding  the  cell  a  =  gl[0],  h  =  gO[l],  c  =  g0[2].  The  6  test  lines  are  shown  in  Figure 
18a.  If  we  must  perform  the  intersection  test,  it  is  done  parametrically  with  a  double  calculation.  If  is 
not  possible  to  do  the  calculation  in  integer  space  because  we  can  not  guarantee  that  the  intermediate 
result  will  not  overhow.  If  the  intersection  parameter  lies  between  qi  and  qi+i,  the  edges  intersect  within 
the  triangle,  and  it  is  accepted.  If  not,  we  keep  track  of  where  the  intersection  occurred,  below  the  low 
end  or  above  the  high  end.  This  test  is  performed  against  each  triangle  edge  and  each  cell  edge  until  a 
crossing  is  found,  or  until  we  see  that  we  have  already  visited  the  cell  edge  with  a  crossing  once  in  each 
direction  (low  and  high).  If  no  such  event  occurs,  the  triangle  is  rejected  and  the  routine  terminates. 
Otherwise,  the  triangle  is  added  to  the  quadtree  leaf  node. 

The  interval  marking  operation  is  done  for  efficiency  as  it  will  potentially  hnd  an  accept  before  an 
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sa  =  101  sqO  =  111 
sb  = 110  sql  = 111 
sc  =  111  sq2  =  100 


sa  =  100  sqO  =  01 1 
sb  =  110  sql  =  101 
sc  =  011  sq2  =  110 


Figure  18)  Triangle  intersection  test  a)  Quadtree  q0,ql,q2.  Triangle  vertices  are  tested  against  lines  shown.  Lines  are 
labeled  with  corresponding  bit  test  variables,  sa,sb, sc, sqO, sql, sq2.  b)  (sa&:s6&:sc)  =  100,  vertex  vO  is  interior  and  triangle  is 
accepted,  c)  Edge  vOvl  is  trivially  rejected  because  of  test  sql.  Likewise  for  vlv2  for  test  sb.  After  parametric  intersection 
test,  triangle  is  accepted,  d)  Edge  vOvl  intersects  below  the  range  on  edge  qlq2.  Edge  vlv2  intersects  above  the  range  on 
edge  qlq2.  Therefore  the  triangle  is  accepted  without  having  to  do  further  testing. 


intersection  in  the  interval  is  found.  Figure  18c  shows  an  example.  Triangle  edge  tOtl  crosses  quadtree 
edge  qOql  at  the  lower  end  of  the  boundary.  So  the  triangle  is  not  accepted.  Triangle  edge  tlt2  crosses 
the  same  edge  at  the  upper  end  of  the  boundary.  With  this  information  alone  the  triangle  cannot  be 
accepted.  The  triangle,  however,  must  intersect  the  cell  if  the  intersection  occurs  above  and  below  the 
range  for  any  triangle  edge  pair  and  any  cell  edge.  The  triangle  can  therefore  be  accepted  at  this  point 
without  any  further  testing.  In  the  worst  case  on  an  accept,  we  will  have  to  do  2  intersection  tests  with 
3  additions/subtractions,  one  multiply  and  divide  with  double  precision  math.  We  pre-calculate  the 
triangle  edge  differences  (tl  —  t0,t2  —  tl,tO  —  t2)  and  pass  them  with  the  triangle,  so  only  a  single  add, 
multiply,  and  divide  are  required  for  each  intersection  test.  In  the  case  of  an  eventual  reject,  it  is  again 
a  worst  case  of  2  intersection  tests. 

If  the  current  viewpoint  coincides  with  the  canonical  view,  only  the  projection  of  the  near  (or  far) 
frustum  face  triangles  need  be  tested  (see  Figure  16c).  This  is  an  efficient  test  in  general,  but  in  some 
cases  is  too  conservative  to  be  useful.  If,  for  example,  the  user  backs  up,  the  projection  of  the  frustum 
covers  the  entire  sphere  (see  Figure  16d). 

3.4  Rendering  During  View  Motion 

When  the  viewer  is  moving,  no  new  samples  are  sent  to  the  display  driver.  The  general  algorithm 
described  in  Section  3.1  is  applied  during  motion.  Because  the  mesh  is  constructed  relative  to  the 
canonical  viewpoint,  all  views  that  share  that  viewpoint  will  get  a  “correct”  image,  to  the  resolution 
of  the  provided  samples  just  by  rendering  the  3D  mesh.  Once  the  observer  moves  off  of  the  canonical 
viewpoint,  artifacts  will  become  visible  when  previously  occluded  areas  come  into  view.  We  accept  these 
artifacts  during  motion.  Once  the  viewer  stops,  however,  if  the  view  has  moved  far  beyond  the  canonical 
view,  the  mesh  is  rebuilt  from  the  new  view  (this  is  described  in  more  detail  in  section  3.5). 

To  optimize  the  rendering  during  motion,  we  hrst  apply  view  frustum  culling  and  only  draw  those 
triangles  that  are  marked  as  visible  .  In  addition,  we  utilize  the  spherical  quadtree  and  OpenGL  display 
lists  to  improve  rendering  performance.  When  the  view  starts  changing,  we  hrst  mark  all  quadtree  nodes 
that  are  visible  within  the  current  view,  as  described  in  the  previous  section.  The  quadtree  is  traversed 
only  to  some  predehned  level.  For  each  visible  node  at  that  level,  the  triangles  are  rendered  into  a  display 
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list  and  displayed.  The  display  list  is  stored  with  the  node.  For  each  new  view,  the  quadtree  is  traversed, 
and  the  nodes  within  the  new  view  are  visited:  if  a  display  list  exists  already,  it  is  simply  called;  if  this 
is  the  hrst  time  the  node  has  been  visited,  a  display  list  is  created  and  stored.  This  rendering  is  actually 
performed  in  two  passes,  and  two  corresponding  sets  of  display  lists  are  potentially  stored  per  node,  one 
for  background  triangles  and  one  for  foreground  triangles.  This  is  necessary  in  order  to  get  the  overall 
rendering  order  correct.  It  also  makes  it  possible  to  perform  the  necessary  translate  and  scale  operations 
of  the  background  triangles  once  in  the  outer  loop  as  matrix  transformation  calls.  This  information  is 
view  dependent  and  therefore  these  operations  must  be  pushed  to  the  outer  loop,  not  only  for  efhciency, 
but  also  to  allow  the  re-use  of  display  lists  between  views. 

The  traversal  progresses  only  to  the  specihed  level.  When  a  display  list  is  created  for  a  node,  all 
of  the  nodes  children  are  visited  and  the  associated  triangles  rendered.  Because  triangles  can  span 
multiple  nodes,  they  may  be  visited  multiple  times  in  the  traversal  of  a  subtree.  Within  the  creation  of 
a  single  display  list,  the  triangles  are  marked  when  they  are  hrst  visited,  and  therefore  only  drawn  once. 
Triangles  can  also  span  nodes  at  the  level  that  the  display  lists  are  being  created.  In  this  case,  they 
must  be  rendered  in  both  display  lists,  because  it  is  not  known  a  priori  if  both  nodes  will  be  visible  in  a 
particular  view. 

There  is  a  tradeoff  between  how  many  levels  to  traverse  in  the  tree  and  how  many  display  lists  to 
store,  and  how  many  non-visible  triangles  get  rendered  because  the  node  size  is  coarser  than  the  frustum 
size,  and  how  many  redundant  triangles  get  drawn  because  of  overlap  across  display  lists.  We  have  found 
traversing  two  levels  to  work  well  in  practice.  Because  the  number  of  nodes  is  small,  the  corresponding 
display  lists  are  stored  in  a  hxed  array  whose  ordering  corresponds  to  a  breadth  hrst  traversal  of  the 
quadtree.  If  signihcantly  more  levels  were  to  be  traversed  on  average,  some  sort  of  hashing  scheme  would 
be  preferable. 

3.4.1  Approximate  rendering 

For  lower  end  machines  and  complex  scenes,  we  have  implemented  an  approximate  rendering  scheme  that 
is  invoked  if  the  frame  rate  drops  below  a  set  rate  during  motion.  This  approach  renders  an  approximation 
to  the  current  mesh  based  on  the  spherical  quadtree  subdivision.  The  quadtree  is  traversed  to  an 
adaptively  specihed  level  depending  on  a  given  quality  based  on  the  current  frame  rate  and  desired 
interaction  speed.  The  lower  the  quality,  the  fewer  quadtree  levels  visited  and  the  coarser,  and  more 
quickly  rendered,  the  approximation.  The  triangles  forming  the  quadtree  subdivision  are  drawn  relative 
to  the  current  viewpoint,  with  a  depth  and  color  averaged  from  all  of  the  mesh  triangles  that  lie  beneath 
that  node.  Figure  20  shows  an  example  scene  on  the  left,  and  the  same  scene  on  the  right  rendered  with 
the  approximation. 

3.5  Mesh  Rebuilding 

If  the  view  has  moved  a  relatively  large  amount  off  the  current  view,  we  must  rebuild  the  mesh  with  a 
new  canonical  view  to  avoid  rendering  artifacts.  When  the  mesh  is  being  constructed,  we  keep  track  of 
the  average  distance  of  the  sample  points  to  the  canonical  view.  Once  the  view  moves  a  percentage  of 
this  distance  off  of  the  canonical  view,  the  mesh  is  rebuilt.  We  have  found  a  value  of  10%  to  work  well 
in  practice.  With  this  simple  heuristic,  larger  view  motions  are  allowed  when  the  scene  geometry  lies  far 
from  the  viewpoint,  and  therefore  artifacts  are  less  noticeable,  than  when  the  viewed  objects  are  close 
in  the  foreground.  This  process  can  be  slow  if  there  are  many  samples,  and  therefore  we  hrst  cull  the 
samples  to  the  new  view  frustum  and  only  re-insert  those  samples  that  are  relevant  to  the  current  view. 


4  Results 

We  have  implemented  the  dynamic  mesh  algorithms  and  the  display  driver  interface  for  the  holodeck 
ray  cache  system.  We  evaluate  our  representation  in  this  context  according  to  the  following  criteria: 
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•  Image  quality:  The  representation  should  provide  a  reasonable  image  given  a  sparse  set  of 
samples,  and  progressively  rehne  as  more  samples  are  made  available. 

•  Update  Speed:  The  display  should  be  able  to  update  the  view  as  fast  as  the  server  can  provide 
samples,  either  from  the  cache,  or  from  the  ray-tracer(s)  performing  the  sample  generation. 

•  Feedback  during  Motion:  The  representation  should  give  the  viewer  reasonable  interactive 
feedback  during  motion,  although  the  display  need  not  be  at  full  quality. 

In  terms  of  image  quality,  the  mesh  representation  provides  a  reasonable  interpolation  of  the  sparse 
sample  set  available  at  start-up,  and  the  image  is  progressively  rehned  as  more  information  is  received.  In 
the  limit,  the  image  converges  to  the  screen  resolution  as  our  mesh  representation  will  rehne  to  sub-pixel 
triangle  sizes.  Figure  19  shows  some  example  images.  The  most  notable  artifact  in  our  images  is  the 
lack  of  sharp  edges.  The  human  visual  system  is  very  sensitive  to  discontinuities  in  the  image,  especially 
at  the  silhouette  boundaries  of  recognizable  objects  in  the  scene.  Even  in  a  higher  resolution  image  as 
in  the  lower  right.  Figure  20,  the  lack  of  clean  edges  is  noticeable. 

Running  on  a  low-end  SGI  02  workstation,  about  10,000  samples  can  be  added  to  the  mesh  per 
second.  This  rate  is  sufficient  to  keep  up  with  a  single  ray-trace  process  during  progressive  rehnement, 
but  is  not  able  to  update  the  display  and  representation  as  fast  as  the  server  can  deliver  samples  in 
the  case  of  cached  rays.  When  run  on  an  Onyx2  with  21  processors  dedicated  to  the  task,  the  sample 
generation  achieves  a  near  linear  speed-up.  Unfortunately,  the  display  generation  is  not  parallelized,  and 
while  the  representation  generation  and  rendering  is  certainly  faster  with  the  beneht  of  a  better  CPU 
and  IR  graphics,  it  cannot  flush  the  sample  queue  fast  enough  to  keep  up  with  the  ray-tracers. 

On  the  02  system,  while  the  interaction  speed  is  sufficient  to  move  about  the  environment,  the  motion 
is  jerky.  Often  during  motion,  the  approximate  rendering  scheme  is  activated  because  the  rendering  of 
the  triangles  is  too  slow  to  keep  the  frame  rate.  The  most  noticeable  performance  dehciency  occurs  when 
the  viewer  has  paused  after  motion,  and  the  entire  representation  must  be  re-generated.  This  lag  can 
be  on  the  order  of  a  couple  minutes  for  a  scene  in  which  we  have  10s  of  thousands  of  samples  cached 
for  the  now  visible  portion  of  the  environment.  On  the  higher  end  conhguration,  we  see  the  interaction 
performance  rise  to  a  usable  level.  With  the  display  list  rendering,  we  get  fairly  smooth  interaction 
during  motion. 

The  image  quality  during  motion  varies  according  to  where  the  observer  moves  relative  to  the  current 
view.  If  the  motion  is  relatively  small,  the  re-projection  of  the  mesh  produces  a  reasonable  image.  One 
can  zoom  in  on  a  point,  for  example,  and  get  the  desired  effect  of  that  portion  of  the  environment 
enlarging,  without  producing  gaps  at  closer  inspection.  If  the  viewer  translates  or  pivots  about  a  point, 
the  appropriate  parallax  effect  will  be  generated  because  we  maintain  the  3D  information.  Once  the 
view  strays  too  far  in  this  case,  areas  that  have  not  been  previously  seen  will  become  exposed.  If  the 
viewer  then  pauses,  this  information  will  be  hlled  in. 


5  Conclusion 

In  evaluating  the  results  of  this  prototype  of  the  dynamic  mesh  display  representation,  we  feel  that  the 
representation  succeeds  in  dynamically  providing  a  reasonable  reconstruction  of  a  constantly  changing 
sample  set,  which  at  times  is  very  sparse.  The  current  implementation,  however,  falls  short  of  our  goals, 
most  notably  in  the  area  of  performance.  We  feel  that  this  hrst  attempt  could  be  improved  upon  in 
several  ways. 

The  use  of  the  rendering  hardware  to  perform  barycentric  interpolation  of  the  sample  values  provides 
a  quick  image  reconstruction.  This  approach,  however,  does  not  capture  the  important  color  and  depth 
discontinuities  in  the  environment  that  result  in  sharp  edges  in  the  image.  We  intend  to  explore  inserting 
edges  at  such  discontinuities,  forming  a  constrained  Delaunay  triangulation.  We  will  also  consider 
creating  a  layered  spherical  mesh  representation  where  the  presence  of  discontinuities  in  the  input  would 
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cause  the  set  of  far  away  points  to  be  put  in  another  mesh  layer  forming  an  onion-like  structure  based 
around  the  canonical  viewpoint. 

In  regards  to  performance,  the  rebuilding  of  the  mesh  after  large  view  motions  is  currently  a  major 
bottleneck.  We  plan  to  experiment  with  an  evolving  mesh  where  the  spherical  topology  can  be  continu¬ 
ously  updated  and  re-used  between  adjacent  views,  removing  the  current  lag  that  now  occurs  whenever 
the  entire  mesh  needs  to  be  re-built. 

We  also  plan  to  investigate  the  use  of  the  dynamic  mesh  in  other  environments,  with  sampled  data 
coming  from  both  real-world  and  synthetic  environments. 


Appendix 

A  Holodeck  System  Display  Driver  Interface 

The  basic  tasks  specified  in  the  interface  with  the  display  driver  are  the  following:  incrementally  create 
a  display  representation  from  a  given  set  of  samples;  render  the  representation  for  a  specihed  view.  We 
categorize  these  tasks  as  mesh  construction,  and  rendering.  The  specihc  interface  is  listed  below  and 
each  task  is  described  in  more  detail  in  the  following  sections. 

•  Mesh  Construction 

—  Init(n):  Initialize  representation  for  at  least  n  samples.  If  n  is  0,  clear  data  structures. 
Return  number  allocated. 

—  NewSamp(c,p,d):  Add  new  sample  with  color  (RGBE)  c,  world  intersection  point  p,  and  ray 
direction  d  to  representation;  remove  old  samples  as  necessary.  Return  identiher  to  associate 
with  sample.  Sample  should  be  output  in  next  call  to  Update. 

•  Rendering 

—  Update(vp, quality):  Draw  the  display  representation  using  OpenGL  calls.  Assume  that 
current  view  specihed  by  vp  has  been  set  up  and  that  the  frame  buffer  has  been  selected  for 
drawing.  The  quality  level  is  on  a  linear  scale  where  100%  is  full  (hnal)  quality.  It  is  not 
necessary  to  redraw  geometry  that  has  been  output  since  the  last  call  to  Clean)). 

—  Clean)):  This  is  called  after  the  display  has  been  effectively  cleared,  meaning  that  all  geom¬ 
etry  must  be  resent  down  the  pipeline  in  the  next  call  to  Update)). 

A.l  Implementation  of  Display  driver  interface 

In  the  following  we  summarize  what  operations  are  invoked  by  calls  to  the  display  driver  interface. 

•  Init(n):  C  auses  the  creation  of  the  sample  and  triangle  data  structures  of  size  at  least  n  samples. 
If  n  <=  0,  the  mesh  is  cleared  and  the  data  structures  re-initialized. 

•  NewSamp(c,p,d):  The  hrst  time  this  routine  is  called,  the  base  mesh  is  created  with  the  current 
viewpoint.  This  is  the  canonical  viewpoint.  Until  the  viewpoint  changes,  all  new  samples  will  be 
added  to  this  mesh.  On  each  subsequent  call  to  NewSamp,  the  following  steps  are  carried  out: 

1.  Point  location  returns  the  triangle  containing  the  sample  projection. 

2.  Sample  testing  determines  if  the  sample  should  be  included  in  the  mesh. 

3.  Sample  allocation  hnds  a  free  sample.  Existing  samples  may  need  to  be  deleted  to  Rll  this 
request. 

4.  Sample  insertion  creates  new  triangles  and  adds  them  to  the  point  location  data  structure. 
The  involves  possible  swapping  and  deletion  of  triangles  to  maintain  the  Delaunay  condition 
on  the  spherical  mesh 

•  Clean(tmflag):  Sets  a  flag  indicating  that  everything  should  be  rendered  on  the  next  call  to 
Update.  If  tmflag  is  set,  a  flag  indicating  that  tone-mapping  should  be  performed  is  also  set. 

•  Update(view, quality): 

—  Viewer  is  moving:  If  quality  is  set  to  high,  render  display  lists,  otherwise  render  using 
quadtree  approximation. 
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—  Viewer  is  stationary:  If  viewer  has  just  stopped  and  current  viewpoint  is  epsilon  from 
canonical  view,  rebuild  the  mesh,  re-tonemap  and  render  full  result.  Otherwise  if  Clean  has 
been  called,  render  the  display  lists,  re-tone-mapping  if  specihed.  If  Clean  has  not  been  called 
do  an  incremental  render  update  with  the  newly  created  triangles  that  haven’t  been  rendered 
yet. 


B  Calculating  Minimum  Edge  Separation 

Given  the  minimum  and  maximum  angles,  we  can  calculate  what  the  minimum  edge  separation  d  is,  a 
distance  (f)  from  the  vertex  forming  the  minimum  angle.  We  will  assign  e^  =  Again,  looking  at  Figure 
5,  we  wish  to  calculate  cr.  We  use  the  following  constraints  to  hrst  calculate  t,  then  the  halfway  vector 
v: 


r  =  (0.0,  0.0,  1.0)  r  ■  s  =  cos  (f)  r  ■  t  =  cos  (f) 

||s||  =  ||t||  =  1  s  =  (0,  sin ((),  cos  (())  +  ty  =  1  —  cos^  (f>  =  (f> 


{s  —  r)  X  {t  —  r) 

(0,  sin  ((),  cos  (f)  —  1)  X  [txjtyj  cos  (f)  —  1) 

||(s-r)||||(t-r)|| 

sin^  (f)  A  {cos(f)  -  l)2^t2  -1-  t2  _|_  (cos  (f)  -  1)2 

sin  7  = 


(sin  (()(cos  (f)  —  1)  —  (cos  <j)  —  l)ty,  (cos  <j)  —  1)G,  —  sin  4>tx) 
\/2  —  2  cos  4>\/‘2  —  2  cos  (f) 


Let  B  =  cos  (j)  —  A  =  sin  (f)B,  D  =  2  —  2  cos  (f): 


sin  7  = 


{A  -  Bty ,  Btx ,  -  sin 
D 


sm  7  = 


[A-Btyf  +  B'Cl  +  i 


£>2 


A^  _|_  B^ty  —  2ABiy  -\-  B'^tj.  +  sin^  (f>t1 


sin^  7  =  ~  sin^  (l)ty  —  2ABiy  -\-  (A^  +  B'^  sin^  <j)  -\-  sin'^  <j)) 

For  quadratic  equation,  a  =  —  sin^  (f>,b  =  —2AB,  c  =  (A'^  +  B"^  sin^  (f)  -\-  sin'^  (f)  —  sin^  iD^)  Therefore 
t  =  (2.11  X  10“^, —4.99  X  10“'^,  9.99  x  10“^)  .  The  halfway  vector,  normalized:  v  =  (1.05  x 
10“^,  2.23  X  10-11,9.99  x  lO”!). 


C  Forward  Error  Analysis 

C.l  Square  root  round-ofF  error 

For  the  square  root  computation  of  number  x  with  accumulated  round-off  error  a,  we  derive  an  expression 
for  ^ X  A  a  in  terms  of  -Jx\ 
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1  +  - 
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The  second  term  can  be  expressed  as  a  binomial  series:  (  1  + 
and  (“)  =  — e — O  if  ^  Therefore: 

Vn/  n!  — 

oc 

[x  -\-  a)~  =  x~ 

If  we  assume  a  <  x,  the  series  converges. 
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We  hrst  look  at  the  case  where  the  error  term  a  >  0  .  This  is  an  alternating  series.  For  an  alternating 
series,  with  partial  sum  indicated  by  Sj,  |s  —  Sj  |  <  |aj+i|  •  Therefore 


[x  +  a)^  =  X‘ 


1  + 


1  a 

2  X 


Rr 
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where  \R„{^)\  <=  .gv,. 
The  true  value  t 
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We  now  consider  when  a  <  0.  In  this  case,  all  terms  after  the  hrst  in  the  geometric  series  are 
(^)  I  ^  |(„li)|  then  the  remainder  R„{^)  of  approximating  the  square  root  with  only 


negative.  Since 
the  hrst  n  terms  satishes  the  following: 
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The  last  expression  is  a  geometric  series, 
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As  a  worse  case,  we  will  take  a  simpler  expression  which  is  the  upper  bound  of  the  two  cases.  Both 
cases  share  the  hrst  two  terms,  so  we  will  only  consider  the  3rd  term: 


1  /a\  2 
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|2*2  -  2\ax\\  -  2*2 


if  a  <  We  will  use  the  following  for  square  root  computation: 


t  =  SQRT{x)  ±  \^€\SQRT{x)\-\-^\ax  ^\  +  +^\a^x  2 
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C.2  Division  round-ofF  error 

For  division  of  two  terms  x,  y  with  accumulated  round-off  error,  a,  /3:  ,  we  derive  an  expression  in 

terms  of 
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Figure  19)  Selected  images:  In  each  case  the  left  image  shows  the  display  when  the  view  is  first  seen,  and  the  right  image  after 
the  viewer  pauses  a  few  minutes  at  the  same  location- 
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Figure  20:  Approximate  Rendering:  Mesh  rendering  is  shown,  and  then  example  approximate  renderings  used  in  motion. 
Extinquisher  image  after  5  minutes  on  an  02,  zoomed  version  on  right. 
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